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Preface 


The  Army  ’s  Arrovo  Center  at  1<AND  conducted  a  special  assistance  studv  on  the 
Operation  Desert  Shield  (ODS)  deployments.  Inihated  in  earlv  September  1990 
at  the  request  ot  the  Chief  of  Staff  of  the  Army,  its  objectives  were  to  understand 
and  report  on  how  the  Army  's  experience  in  ODS  might  influence  the  future 
Army — its  planning  systems,  force  structure,  support  capabilities,  equipment 
neeiis,  .ind  dcplovment  require.uciits.  Tlie  study  also  vi-uiiplemented  several 
other  Arroy’o  Center  research  efforts  addressing  the  Army's  mvolvcment  m  the 
operations  in  Southwest  Asia,  including  work  sponsored  by  the  U.S.  Forces 
Command  on  alternative  Army  force  structures  and  active  and  reserve  mixes. 
These  research  projects  provide  a  broad  perspective  on  the  challenges 
confrontuig  the  Army  as  it  transforms  itself  into  a  force  more  oriented  toward 
contingency’  operations. 

This  monograph  documents  the  Army's  experiences  with  deployment  planning 
and  with  deployment-planning  systems  during  ODS.  It  describes  the  plannmg 
environment  and  expectations  prior  to  the  crisis  and  then  documents  how  ODS 
experiences  differed  from  those  expectations.  It  offers  suggestions  as  to  how, 
from  the  Army's  point  of  view,  planning  personnel,  procedures,  and  systems 
might  have  been  used  better  during  ODS  and  how  they  might  be  improved  for 
future  deployments. 

Interest  expressed  by  the  Jomt  Staff  in  this  research  prompted  RAND's  National 
Defense  Research  Institute  to  contribute  to  its  pubbeation. 

Although  .  ..vused  on  Army  experiences,  this  document  should  be  of  interest  to 
operation  and  logistic  planners  m  all  the  services  and,  especially,  to  the  militarv 
and  civilian  officials  charged  with  improving  deployment  procedures  and 
execution. 


The  Arroyo  Center 

Tine  Arroyo  Center  is  the  U.S.  Aimy's  federally  funded  research  and 
development  center  (FFRDC;  for  studies  and  analysis  operated  by  RAiND.  The 
Arroyo  Center  provides  the  Army  with  objective,  independent  analytic  research 
on  major  policy  and  organizational  concerns,  emphasizing  mid-  and  long-term 
problep's.  Its  research  is  carried  out  in  four  programs:  Strategy  and  Doctrine; 


IV 


Fdrce  Development  and  Technology;  Mililarv  Logistics;  and  Manpower  and 
Training. 

ArrrA'  Regulation  5-21  contains  basic  policv  for  the  conduct  of  the  Arroyo  Center. 
Tne  Armv  provides  continuing  guidance  and  oversight  through  the  Arro\  o 
Center  Policy  Committee  '.ACPC),  which,  is  co-chaired  by  the  Vici'  Chief  of  Staff 
and  bv  the  .Assistant  Secretary.'  for  Research,  Development,  and  Acquisition. 
.Arrovo  Center  work  is  performed  under  contract  MDA903-91-C-0006. 

The  .Arrovn  Center  is  housed  in  R-AND's  .Armv  Resemh  Dii  isien.  R.AND  is  a 
private,  nonprofit  institution  that  conducts  analytic  research  on  a  wide  range  cif 
public  policy  matters  affectmg  the  nation's  security  and  welfare. 

James  T.  Qumlivan  is  Vice  President  for  the  .Armv  Research  Div  ision  and  the 
Director  of  the  .Arroyo  Center  Those  interested  in  further  information  about  the 
•Arrovo  Center  should  contact  his  office  directly: 

jame.s  T.  Qumlivan 
RAND 

1700  Mam  Street 
P  C.  Box  2138 

Santa  .Monica,  C.A  90407-2138 
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Summary 


During  the  six  months  of  Operation  Desert  Shield  (CDS)  the  U  S.  Arm\'  selected 
nearly  300,000  troops  and  over  1,000, tXX)  tons  ot  equipment  and  supplies  tor 
deplovTnent  to  Saudi  Arabia.  It  informed  the  U.S.  Transportation  Command  ot 
where  and  when  tliose  troops,  equipment,  and  supplies  would  be  massed  for 
intertheater  movement,  and  then  moved  the  troops  and  cargoes  to  tiaose  port.-  of 
embarkation.  It  loaded  the  ships.  And,  after  the  troops  and  cargoes  were 
airlifted  and  sealifted  to  their  ports  of  debarkation  on  the  .‘\rabian  penmsula. 
Army  persormel  received  the  aircraft,  unloaded  over  400  ships,  remated  troops 
with  their  equipment  and  suppUes,  and  organized  transport  to  mo\  e  the 
reconstituted  units  into  combat  positions.  The\  also  provided  many  of  those 
services  to  elements  of  the  Marines  and  other  Services. 

/\nalysis  of  ODS  experiences  suggests  that,  despite  lack  of  comparable  standards. 
Army  deploxments  were  planned  and  executed  reasonably  quicklv  and 
smoothiv  and  were  possible  (on  such  a  scale  and  schedule)  primarilv  because  of 
the  intelligence  and  can-do  attitude  of  the  personnel  and  the  existence  of  modem 
planning  procedures  and  computerized  infomiahon  flow's.  .-Analysis  also  reveals 
areas  where  those  personnel,  procedures,  and  support  require  improvement. 

At  the  beginning  of  ODS,  few  U.S.  planners  were  proficient  in  real-time 
operations.  Recent  military  operations  had  been  either  small,  well  planned  in 
advance,  or  both.  Some  planners  were  export  in  deliberate  planning— the  slow 
and  considered  development  of  dptmled  and  coordinated  operation  and 
deployment  plans  for  well-specified  exigencies.  Others  were  expert  ui 
deployment  operations,  but  almost  exclusively  in  scenarios  or  exercises  that  had 
been  preplanned  (and  well  planned),  and  in  which  operations  alwavs  prcx'ecded 
according  to  plan.  In  fact,  nearly  all  U.S.  planning  activities  and  exercises 
assumed  that  (a)  the  threat  and  the  proper  U.S.  response  tc>  the  threat  (and  thus 
the  mission  for  the  Army  and  other  Scrx'ices)  were  clearly  defuied,  (b)  tlie  forces 
necessary  to  handle  the  cnsis  and  tfie  transport  lliey  required  were  obvious  and 
ready;  and  ^c)  few-  changes  or  updates  to  tlie  plans  were  ever  nccessarv . 

Operation  Desert  Shield  did  not  follow-  that  book;  Uiere  was  net  earlv  warning,  no 
plan  on  the  shelf  ready  to  execute,  and  m  tlie  bcginnmg  not  even  a  good  idea  of 
die  U.S.  mis.sion  or  of  how  many  troops  might  be  needed.  Instead,  tlie  Iraqi 
mvasion  of  Kuwait  and  the  threat  to  Saudi  Arabia  presented  U.S.  planners  with 


till’  i:hiillonj;i'  ol  piannini;  tliu  deplovinont  oi  nolAi'l-'-pivitiivi  lo'  a r.ij'uii', 
into  a  lluMt'-T  v'k'.iNcd  In  uncortaints .  I'lamu-rs  h.ui  to  impiin  i>o  and  luiild 
constantly  cc  oK  ui^  cinplovnu'iit  and  dcplov iiiont  plans,  w  lulo  at  tliyv.uiu’  Inno 
tlu’ir  i  olloapucs  n  cro  ph\>.icalK  doplin  inp  tlio  iir.tiai  i\  a\ o  oi  coini  .ii  aiui 
support  units. 

By  ihf  ond  ot  tlio  dopkiyiiients  poopk'  had  Been  trainod,  priKiiiuros  had  bi  i  ii 
di.'buj;ped,  and  dn  orso  sv' toms  had  boon  patchod  topothor  In  thus  m  nst.',  and 
bocauso  tho  onom\'  mnuntoii  hnv  eftoctiv  o  oporations,  sliould  bo  \  lovM-d  a-  a 
\  aluablo  loaniinp  oxporionco  It  '  allovl  upon  to  ropheate  thino  doph".  luonl- 
todas',  tho  Army  s  actions  and  roactions  (and  iiuiood  those  ol  all  tho  L  .S  Son,  ko> 
and  dotonso  organizations)  would  be  subslantialK  taster  and  smoother  1  he 
challenge  is  to  loam  and  to  gonoralizt.s— tii  leani  irom  t">l>S  the  improi  enu'iit.-  in 
priKodures,  systems,  and  practices  that  can  bo  used  ottoi  li\  ely  m  lulute, 
dissimilar  crises. 


Procedures  Should  Be  Improved 


I’  'rhaps  the  most  important  lesson  from  OL>'  is  tb.at  \ve  need  to  ro-ex.iinine  how 


I'l  i  ^  /-»«  ♦  r>  I 

.  .  s»s  J.-, 
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unexpected  and  unpkumed-for  regional  crises  now  seem  to  (’oso  the  most 
probable  threats  to  the  U.S.  security. 


01)5  demonstrated  that  political  sensituities  e.isiK  can  cause  initial  planning 
actiyities  to  be  close-held  at  tho  highest  leyeis.  forcing  lower-lei  el  organizations 
either  to  bide  tlieir  time  or  to  mitiaie  early  planning  without  cIcarK  stated 
missions  or  obji-ctiv  es.  Even  after  the  lull  planning  and  executii'n  communits 
was  alknyed  access  to  and  participation  m  OPS  planning,  howeyei ,  ma)or 
uncertainties  continued  as  perceptions  »)t  the  world,  theenenn  ,  mii  po>sibk' 
actions,  and  his  possible  reactions  changed  almost  daily.  Futiiro  crises  ma\  ditier 
trom  ODS  m  many  ways,  hut  we  expect  that,  at  least  m  llv’tr  initial  siages,  most 
will  exiiibit  significant  if  not  similar  seiisitiyities  and  uncertainties. 


Accepting  that  as  the  nonn,  OPS  experiences  suggest  that  privedures  lur 
deployment  planning  should  be  repackaged  to  emphasize  flexibility  and 
adaptability  LX’liberate-plannmg  actiyities  should  emphasize  detailed  plannirg 
only  wiliim  the  context  of  learning  how  to  plan,  of  establishing  relationships  with 
other  planning  and  execution  organizations,  and  ol  acquiring  l.imilMrits  witti 
foreign  regions  and  their  customs  anil  reso’urces  Crisis-[''lanning  aclii  itios 
should  stress  and  facilitate  concurrent  planning  and  executiini,  they  sluniki 
ackno  sledge  tha:  mo.st  cr will  rispu'e  ‘-at'er  a  imw  operation  plan  lOl’L.AN) 
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and  tinii'  , 'halt'd  lorcc  and  iiu'nl  d.Ua  f  l  iTUD)  or,  at  tlri  loa.''*,  muiii'diatc 

arid  ..f;nit,L'aiit  ..har.^’.v>  to  oxi.-tuij;  Init  dalod  plan.-  anti  databai  o^ 

C  ri.-'i.-'  at  tiL'n  priKOtitirts  tiunilti  stroi'S  imiltilfx fl  planninj;.  tlu'  usi-  t'l  appropato 
data  til  cstmrato  lirst-round  n^'l'd^.  tapal'ilitu's,  and  pt'ssibilitu  s,  and  tlif  uso  ot 
di'taik'd  data  to  plan  and  oxotuto  actu.d  ino\  oim-nt.-.  CDS  t'iticiab-  foininonh- 
worked  w  ith  throe  and  tour  loi  ois  ot  data;  l  liov  u^cd  appropato  i  tort  o  lot  ol  and 
nnit-lt'fol)  data  in  inutli  ot  thoir  plaitninp,  in  contnnrnicatiinw,  and  in  Mtuation 
roportinp;  thov  u.'-od  nioro  dotailod  tiinit-hno-nuinbor  lovol)  intormation 
w  honot  or  tlu't  w  ore  iin  olt  I'd  w  ith  tho  Joint  Opoiation  Planninp  anti  Lxe  /ution 
Stwtom  aird  lt^  apphtations,  and  thot  usod  oton  ini'ro  dotailod  inli'nnation  lat 
tlio  piooo  vind  poiMin  lot  oi)  in  planninp  and  oxotutinp  tho  at  luai  mot  os.  That 
oxpononoo  nood>  to  bo  intorpotati-d  inti'  inaiuiai.s  and  traininp 

ODS  expononcoj-  al.so  'Uppost  tho  .\rniv  >hould  (a)  dovolttp  tailorablo  ttirco 
f'at'kapos  tor  both  combat  aiui  support  units,  tomploto  w  ith  oipnpniont  lists  and 
stow  fslans,  and  (b.l  w  ork  with  tho  joint  Statt  in  do'.  olopinp  tlix  trino  and 
institutions  tor  -upport  coinmaiui  and  lontro!  orpani/ations  and  for  support 
packapos  tor  dittoront  v  lassos  ot  continponcios  and  ditloront  typos  ol  tlioators. 

Support  Systems  Should  Be  Rethought,  Then  Updated 

Al'tor  continpont\'-(’lanninp  .urd  oxocution  privoduros  haoo  biTn  roltvusod,  tlioir 
computerized  support  equipment  and  applications  should  be  reassessed. 

Amiv  experiences  in  ODS  sup.pest  that  the  computerized  deployment-support 
svstonis  need  to  bo  retiKusod  and  updated.  At  tho  lughost  loool,  planners  at  tho 
National  Contmand  Authorities,  Chairman  of  tho  Joint  Chiols  ol  Staff,  tiro  theater 
Commander  in  Chief  (CINC),  and  U.S  Irairsportation  Conmrand  need 
autonrated  tools  lor  planning  and  gaming  (in  the  fonn  of  what-il  scenarios  based 
I’H  the  CLNC's  evoK mg  Ol’LAN  or  course  of  action)  as  aids  ur  decisionmaking. 
Tlrev  nrust  haee  immediate  access  to  aggregate  planning  tixrl.s  that  can  operate 
with  incomplete,  preliminary  inlornration.  Thev  must  liavo  means  for 
conturuallr'  incorpi'rating  newer  and  nrore  complete  mionnation  and  plamring 
guidance  inter  their  airah  sos  aird  evolving  plans  Meaningful  links  must  he 
developed  het.voen  elements  ol  urtoniiatioir  as  tJro\  boconro  ai  ailablo  and  ari‘ 
updated;  this  iirtonrration  nrust  bo  nraintaiirod  iir  a  database  triuir  which  selected, 
roloi  airt  subsets  can  bo  lunrislrid  to  tho  Joint  ['laniring  and  execution  commumt) 

ariiC) 

As  the  planning  proceixis,  means  must  he  established  for  lurking  tiro  sex  oral 
le\e!s  of  data — lories,  units,  unit  line  iriimheis  (ULN).  and  persons /piece. - so 


til, it  j'l.ui'iini.’,  .liid  di.'pl''\ii,  [It--  ^-.1)1  tv  ii'iioiKtoti  i-lii-t  tiM'ii  and  t.'llii:ii.’ntl\  In' 
tlu'  ;ii'i.'r,'.liiip  ,\ikI  ti,iii^|Hiii.:ii,in  i.oiniiia!id>  .uui,  at  thn  hanit.’  tinii',  nu'niti.ir<.’d 
and  i, not d mated  tn  tlu'  luj’jii't-kn  i'l  romniar.ds.  Unw  tho  M  stcins  .ind  data'oas'  - 
.iri’  mtcpr.ilrii  '.u  inters tiiiiii\  i,\i  i>  .in  npi  n  i>i-in-,  I'lit  it  inu;-!  lU't  tv  ,i  simple 
botti'ins-iip  >\  st«.'m  I't'lli  n.Umiial  nitKiaK  and  mivi-lin  cl  pl.miH'is  nuist  hi  .iblc 
to  spiv  it\  and  aiuiK  .'i-  lon  e  atui  unit-lm  el  oper.itu'ns  wlu  tlu  i  oi  not  L'LN  .mil 
person,  pien'  li.il.i  .iri'  .u  .iiiabi.'. 

Sinul.irK',  means  imisl  I'e  dei  eliiped  lor  linkinp  tlic  se\ vral  io\  els  o! 
eomnumu  at  ion--  vo  lb,, it  pl.innmp  ,md  deploi  nienis  can  be  ^oiuiui  ti  d  In'  thi' 
oj'er.iliiiv;  and  tr.in'-pert.'.l ion  eoiiiiiiands  and,  at  tlu'  s.inie  timi',  moniti'red  .uui 
eoordin.iied  In  liiplu'r-le\ ei  eomniaiuls  A.idilii-nal  .lelioiis  the  .Anrii  nuphi  take 
to  npat.uie  Its  lii'pKn  nii-nt  ,  .ip.ibiliti  .iri-  diseiisscii  in  the  bt'de  oi  this  report. 

Miisl  importantli ,  hone'.  er,  .-Xriiu  .uui  JI'LC  personnel  nuist  realize  that  tor  the 
foresi'eable  tuture,  rep.iriiless  ot  ne.ir-lerni  or  e\  en  iniil-terni  iniprm  eilient.,  in 
the  suj^pon  s\  sii'iiis,  those  s\  sti'iiis  will  eontinue  to  exhibit  delicieneies  and 
short-lalls  ,ind,  m  p.irlieul.ir,  th.'.l  there  will  alw.v.'s  be  delays  in  geltiny;  up  to 
sjii'ed  t.wt  enoueji  111  IK'-  and  slu'rt-wan'inp,  eii.ses.  Hi^li-slre.ss  aetn  ities  such  as 
brinpiny;  systems  up  to  speed,  ereatiiig  and  iinprin  in^  dat.ib.ises,  and  vs  orkm^ 
around  bottlene,:ks  ,uid  delu  RT.eies  will  eontinue  to  challenge  crisis-actiiin 
priieedures,  si  stenis,  ,md  persi'iinel. 

Personnel  Skills  Should  Be  Refocused  and  Upgraded 

It  we  aeeept  tlu'  premise  that  future  crises  vvill  usualh'  arrive  unannoiuiced  and 
that  pl.iniimg  and  support  systems  will  continue  to  e\  ol\  e  rapidly — constantlv 
impnn  ing  and  exp.mdmg  e.ipabilities  and  constantlv  elulleiiginp  operator 
skill — then  the  most  critic.d  element  oi  the  deplovnu  nl-pl.uining  system  will 
continue  to  be  it-,  juTsonnel  the  soldiers  and  civilians  who,  witii  wh.itex  er  toi'ls 
are  then  avail.ibii',  must  qmcklv  and  correctlv  plan  c>peratioiis,  select  units  tor 
dep!o\  ineiit,  pass  along  cargo  mtomiation,  and  supervise  moves  and 
emploN'meiits  To  I’etler  tr.un,  nurture,  and  rewani  thoso  persi'iinei,  the  .Army 
should: 

1  Strengthen  career  p.iths  lot  pi, inning  personnel.  Increase  recognition  ol 
superior  skills,  q.i.iliticiitions,  caid  perlormancc. 

2.  Increase  the  training  and  pr.iclice  ot  those  personiu‘1  m  re.ilistic-plaii,  nm 
plan,  .ind  unex|'ecti'dly  ■'tiesslu!  scen.inos  Restructure  deplovnieiit 
I'xercises  U’  require  personnel  o  use  the  deplovment  supp^ort  svstenis  to  their 


maximum  capabilities,  including  the  rapid  compilation  of  large  TPFDDs,  and 
tlae  rapid  analvsis  and  integration  of  situational  changes. 

Create  ways  to  use  crcsis-planning  tools  in  day-to-day  peacetime  operations. 
This  mav  be  difficult,  but  it  is  necessary  to  erasure  ramilianh'  and  continuing 
compietence. 
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1.  Introduction 


Deployment  is  a  complex  activity.  Deployment  planning  involves  identifymg 
the  threat;  determining  which  types  of  U.S.  units  can  best  counter  and  conquer  it; 
identifying  specific  units  of  those  t^'pes  that  are  combat  ready,  equipped,  and 
available  to  move  in  accordance  with  the  theater  commander  in  chief's  (CINC's) 
schedule;  identifying  and  scheduling  military  and  civilian  aircraft  and  ships  to 
move  those  units  into  the  theater;  providing  for  the  reception  and  onward 
movement  of  those  units;  and  sustaining  them  once  thev  are  there.  All  these 
tasks  were  accomplished  in  Operation  Desert  Shield  (ODS). 

The  deployment  tasks  may  appear  simple,  but  they  require  many  detailed  and 
interdependent  activities  involving  many  organLzahons  and  agencies  (see  Figure 
1).  Tnc  major  tasks  that  most  be  accomplished  in  reasonable  order  for  any 
successful  deployment  mclude 

1.  When  and  as  directed  by  the  Nahonal  Command  AuLhorihcs  (MCA),  the 
Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  tasks  the  theater  CINC  (for  ODS 
this  was  USCDsICCENT,  the  Commander  in  Chief  of  the  U.S.  Central 
Command)  to  develop  the  war  plan.  CJCS  allocates  forces  and  transport  for 
that  plan. 

2.  The  CINC,  in  consultation  with  his  component  commanders,  draws  up  his 
plan  and  decides  on  the  types  of  forces  he  needs,  roughly  in  what  sequence 
or  time-phasin;  he  needs  them,  and  then  allocates  his  transport  accordingly. 

3.  The  Services'  sourcing  agencies  (Forces  Command  [FORSCOM]  for  the 
Army),  workmg  with  the  CINC's  requirements  and  the  CJCS's  allocations, 
then  designates  the  particular  units  that  will  deploy. 

4.  The  CINC's  mitial  call  is  primarily  for  combat  units.  After  those  have  been 
specified,  the  sourcing  agencies,  the  Services,  and  the  CINC  jointlv  determine 
the  support  umts  and  structure  and  the  non-unit  personnel,  supplies,  and 
equipment  that  will  be  needed. 

5.  The  sourcing  agencies  identify  specific  support  elements  and  coordmate 
ready-to-inove  dates  for  both  combat  and  support  units  with  the  CINC  and 
with  the  U  S.  Transportation  Command  (USTRyXNSCOM). 
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Figure  1— Deployment  Planning  Participant: 


6.  Deploying  units,  with  guidance  from  the  CINC  and  the  sourcing  agency  (and 
perhaps  L'STRANSCOM),  estimate  the  number  of  personnel  and  the  items  of 
equipment  (by  number,  type,  weight,  and  size)  they  wish  to  move.  The 
CINC  conhnues  to  coordmate  the  detailed  plan  among  the  Services.  He 
reserves  the  final  authorit)'  over  all  latest  arrival  dates  (LADs). 

7.  The  installation  transportation  officers  supporting  the  deploying  units  (in  the 
Continental  United  States  or  CONUS)  arrange  the  initial  o\  erland  moves  by 
road  or  rail.  The  Transportation  Component  Commands  (TCCs)  arrange  for 
air  and  sea  treinsport  and  for  port  activities. 

8.  The  CINC  coordinates  in-theater  reception  of  the  deploymg  units  and  their 
movement  to  forward  destinations. 

This  might  all  work  efficiently  and  effectively  if  the  plans  were  perfect  (or  nearly 
so)  and  if  nothmg  that  affected  any  of  the  plans  ever  changed.  In  real 
deployments,  however,  many  thmgs  usually  occur  simultaneously,  and  changes 
constemtly  disnipt  aspects  of  the  plan.  The  planning,  the  corrections,  the 
replannmg,  and  the  updates  require  reliable,  secure,  and  often  near-contmuous 
communications  among  the  participants. 
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Deplovment  planning  requires  high-level  decisions  concerning  whether  force 
should  be  emploved,  how  much  and  which  kinds  of  force  to  deploy,  whether  to 
call  up  the  Civil  Reserve  Air  Fleet  (CR.4F)  and/or  the  ships  m  the  Ready  Reser\  c 
Fleet  (RRF),  etc.  It  also  (see  Figure  2)  requires  loxver-level  decisions  and 
information  flows  identitying  which  troops  and  which  cargi>es  will  be  loaded 
onto  which  ships  and  aircraft.  The  planning  procedures  and  svstem.s  that  defuie 
and  facilitate  those  decisions  and  data  flows  are  the  subject  of  this  report.  We 
document  and  examine  Army  experiences  with  those  procedures  and  systems 
during  Operation  Desert  Shield  and  identify  improvements  and  supplemental 
capabilities  that  may  better  serve  future  deployments. 


Purpose  and  Approach 


Operation  Desert  Shield  provided  the  first  large-scale  test  of  modem  deployment 
planning  and  monitoring  procedures  and  their  automated  support  equipment 
Some  procedures  had  proven  useful  in  smaller  operations  and  in  operations  that 
were  not  time  sensitive,  but  ODS  was  different.  ODS  was  a  short-w  arnmg  crisis 
requirmg  immediate  deplo)  mc>nts  that  evolved  into  tlie  largest  deployment  of 
troops  and  equipment  since  World  War  II. 


Figure  2 — Planning  Requires  Multiple,  Concurrent  Pala  Flows 
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Throu>;hout  ODS  the  deployment  planning  commumtv  criticized  the  procedures 
and,  especially,  the  support  equipment.  The  recurring  theme  was  that  JOPES,  the 
Joint  Operation  Plannuig  and  Execution  System,  and  the  other  deployment- 
related  systems  were  of  little  use,  especiall)'  during  the  early  stages  of  the 
deployment. 

This  report  identifies  and  discusses  many  real  problems  with  lOPES,  but  it  also 
argues  that  much  of  the  criticism  early  in  ODS  was  due  to  the  unfam.iliarity  of  the 
plannmg  and  deployment  communities  witli  the  en\  ironmcnt  m  which  the;> 
suddenly  found  themselves.  The  uncertamties  were  greater  m  number  and  more 
substantive  than  expected.  Because  personnel  had  little  realistic  trainmg  in 
dynamic,  no-plan  operations,  many  of  the  initial  efforts  of  the  planning  <md 
execution  community  appeared  confused  and  ineilcctivc. 

This  report  documents  the  Army's  experiences  widi  deploiment  plannmg  and 
with  deplovment-plannmg  systems  durmg  ODS.  It  describes  the  plannmg 
environment  and  expectations  before  ODS  and  then  documents  how  ODS 
experiences  differed  from  those  expectations.  It  offers  suggestions  as  to  how 
plannmg  person  lel,  procedures,  and  systems  might  ha\  e  been  used  better 
durmg  ODS  and  should  now  be  improved  for  future  deployments. 


Outline  of  This  Report 

This  report  is  divided  into  six  sections.  Sections  2  and  3  provide  background  by 
summarizing  Army  and  Jomt  plannmg  procedures  and  systems  as  they  were 
perceived  at  the  beginning  of  ODS.  These  sections  set  the  stage  for  what  follows. 

Section  4  documents  Army  experiences  with  those  procedures,  systems,  and 
support  durmg  the  ODS  deployments.  In  particular,  it  documents  how  the 
plannmg  and  execution  environment  for  this  operation  differed  from  the 
practices  and  exercises  that  had  gone  before.  Section  5  discusses  and  presents 
examples  of  the  types  of  shortcomings  that  surfaced  with  respect  to  the 
computerized  support  systems  during  the  deployment.  Section  b  summarizes 
the  experiences  documented  m  the  report  and  presents  suggestions  for 
structurmg  near-term  improvements  to  the  current  procedures  and  systems  and 
further  research  mto  the  more  basic,  longer-term  issues  associated  with 
deploymg  the  Army  of  the  future. 

Several  appendixes  provide  background  mformation  on  the  support  systems. 
Appendix  A  contams  detailed  mformation  on  the  jomt  automated  mfonnation 
svstcrris  assistmg  deployment  and  operatiems  plannirig  Appendix  B  describes 
tlie  major  Army  support  sys  ems  and  how  they  interact  with  the  Joint  systems. 


2.  Deployment  Planning  Prior  to  ODS 


Deployment  is  a  joint  activity.  Anny  and  Marine  iinits  deploy  on  Air  Force  or 
commercial  aircraft  and  on  Navy  or  comm.ercial  ships,  as  directed  by  the 
commander  in  chief  of  a  theater  unified  command  and  coordinated  bv  the  CINC 
of  the  U.S.  Iransporiation  Command.'  This  section  discusses  the  jomt  planning 
process  and  the  procedures  for  deliberate  and  crisis-action  plannmg  that  were 
current  at  the  time  of  ODS. 

Militarv'  operations  consist  of  a  number  of  distinctly  different  activities,  each  of 
which  must  be  planned,  coordmated,  and  executed.  Major  activities  include 
mobilization,  dcplovTuent,  employment,  sustainment,  and  redeployment. 
Mobilization  involves  the  selection,  activation,  equippmg,  and  movement  of 
reserve  forces.  Deployment  involves  the  strategic  movement  of  forces  and 
support  from  their  home  bases  to  the  location  of  the  conflict.  Employment 
mvolves  the  theater  use  of  combat  forces;  sustainment  mvolves  the  resupply  of 
the  Uieater  forces.  Redeployment  involves  the  subsequent  movement  of 
deployed  uruts  back  to  their  home  bases  or  on  to  new  locations. 

Participants  m  the  operation-planning  process  include  the  National  Command 
Authorities  (NCA),  their  advisers,  supporting  executive-level  agencies,  and  j 
group  collectively  called  the  Jomt  Planning  and  Execution  Community  (JPEC). 
The  JPEC  consists  of  the  commands  and  agencies  involved  in  the  training, 
preparation,  movement,  reception,  employment,  support,  and  sustainment  of 
forces  in  a  theater  of  operations.  This  includes  the  Jomt  Staff,  the  uruhed  and 
specified  commands,  the  Ser\  ice5,  government  agencies  such  as  the  Defense 
Communications  Agency  (EXTA),  the  Defense  Logistics  Agency  (DLA),  and  the 
Defense  Intelligence  Agency  (DIA),  non- Department  of  Defense  (DoD) 
departments  and  agencies,  and  at  times  allied  commands  and  agencies. 

Joint  publications  detail  two  distmcl  types  of  contmgency  planning — peace-time 
or  deliberate  planning’  and  time-bcnsitive  or  cnsiti-action  plannmg — and  state  that  the 
significant  factor  determining  which  type  of  planning  to  employ  is  the  time 


'The  |omt  eperatu'nal  planning  priKes;,  is  defined  in  loinl  Pub.  2  as  "a  coordinate  |oint  staff 
procedure  used  by  a  commander  to  detcirninc  the  best  method  ot  accomplishing  assigned  tasks  and 
to  direct  the  action  necessars  to  accomplish  his  mission."  See  The  Joint  Chiefs  of  Staff,  Unified  Action 
Armed  Fo'cef  UlNAAFi,  JCS  Pub.  2,  Washington  D  C..  December  IVSti.  pp  .1—41 


n\  (iilablo  tor  planning  -  Deliberate  plannuig  ivpiealU  takes  Irani  IS  to  2  nuinths 
and  should  be  used  when  time  permits  the  participation  of  numerous 
commanders  and  staff  from  the  JI’EC.  Deliberate-planning  acti\  ities  pri'duce  a 
concept  plan  (COi\TLAN')  or  operation  plan  (OrLAN),  along  \s  ith  supporting 
plans,  documents,  and  databases  '  Crisis-action  plamnng,  on  t  ie  other  hand,  is 
used  when  the  time  a\  aiJable  tor  plaiuung  is  short  and  armed  forces  tnav  need  to 
be  deployed  and/or  employed  i^uickly c* 

There  is  another,  e\  en  more  significant,  difference  beoveen  tiiem,  hovs  e\  er: 
Crisis-action  prevedures,  unlike  dehberate-plannii\g  procedures,  in\  oK  e  botli 
planning  and  execution.  They  result  in  an  operation  order  (OrORD),  a 
deployment  database  linked  to  the  military-  command  and  control  structure,  and 
the  deplos  nient  and  einplovment  of  militarv  forces.^  Tlius,  i  \  en  m  a  crisis  with 
significant  ach  ance  warning  when  some  or  all  of  the  deliberate-plamung 
acti\  ities  nught  be  used,  the  .esultmg  plans,  documentation,  and  data  must  be 
transferred  into  the  crisis-action  system  before  execution  is  pi-vssible 

ITgure  3  shows  the  relationships  between  deliberate  planning  and  crisis-action 
planning  VN'e  u'lll  schmi  discuss  the  differences  between  the  two  acti\  ities,  but  it 
IS  useful  tirst  t(’  note  the  similarities  and  relationship'  bv‘-»seen  iliem  As  can  be 
seen  in  the  figure,  tlie  /’/(nniiiiy  pr>Ked’ures  are  much  the  same  for  the  two 
activities,  at  least  for  the  first  lour  steps: 

1 .  The  Chairman  of  the  joint  Chiefs  of  Staff,  actmg  for  Uie  Mational  Command 
Authorities,  tasks  a  unified  commander  to  develop  a  -.c  ar  plan.  TTio  CjCS 
alliKates  forces  and  transport  for  that  plan.  TTu*  tasked  commander  becc'nies 
the  "supported"  CINC;  all  other  unified  and  specified  commanders  becon-.o 
"supporting"  Cl.N'Cs.  Tfie  services  are  also  designated  to  suppi'rt  Uie 
oj-ieration. 

‘•Much  of  :hi..  intD'Tnc^lrin  conccniuif’  Itio  loinf  planning  s\ sU*nv,  .=ii J  ttieir 
informatuMT  svsiom  (AlSi  i>  takt'ii  ir4»iii  APX'  J'uh  1.  "Thr  y  vJu.jV.  ’  ip 

partiajlar,  S^viions  ^  ‘.rrt  u,;h  Him  dt'liK'r.itf  plaiimnp,  cnsi5-actK»n  plaTinm^;  .  nd  ruunv 

•''Ilu’  pnKi'dun's  of  dcliSTatt'  plar.niiijk;  aro  in  U'lnf  F'lanpjn^:  "n  slorr  ijOI'S) 

Voliinies  1  and  II  Thosf  \  jIm''  ^ivo  tho  .»Jmi5i:slrativv  rt\^uin‘mcnth  for  pij‘"iishi;.»;  tl^o  plan. 

Its  anru’v»’s.  appondixo.  ett  jOI*^  Vif'umo  111  iniUMJucos  the  a\ ailabk- automata  data  prcvossinj^ 
lAPri  support- 

■^Lach  tvpool  planning  tws,  tintif  fo.nMh  Kvif  supported  b\  it-'itvvn  C'poraiioM 

riannin>;  S\sti'm  was  tite  s\ stem  used  f-'' iieiiht'rate  planmni:  .iikI  the  joiP.‘  I \’plo\  r'.rnt  S\  ''loni  ill  >S'' 
was  ih»^  sx  stpni  ust\J  for  en-  i>'activ>r.  plar.nin):  ajul  JepU'vnieiit  Currenth.'.  a  nevs  s\  stoao  the  Jomi 
Operation  rianPin>,:  and  ution  SvMt  in  ■. lOPEiSi  w  Uvueunp  to  inie^rate  lOO  ar-d  )  1>S  aiui 
depk'vn'eni  p‘  ’  :  ''‘j  ai'd  i  xOvUtion  bvsii’ins  ar*-  J:>rasst'vl  ir.  (he  luwl  n<\(iod 

-'f 'rk\<'‘.u-x.  ;  IS,,  auiop  plannir.^  aro  desentwi  in  joint  Pub  4. /.cf:.’ /’.'jMfifrjy 
'-olui  ‘  k*  is  Action  P'’rcedurts.' 


SOURCE  AmM  Forces  Siaft  Cc'leje  National  Defense  Universiry,  The  jcn;  SU"  Othcers 
Gbiae  :99i.  AFSC  I'uLi  I.  Figure  7-20.  Washington,  D,  C.  U,S  Government  Printing  OMice. 


I  33  I  . 


Figure  running  Sumniarv 


2.  The  supported  CINC  reviews  the  enemy  situation  and  begins  to  coHeet 
mKessary  intelligence. 

3  He  develops  his  plan  or  course  of  action. 

4.  Tfie  plan  is  reviewed  and  tlie  appropriate  course  of  action  selected. 

At  that  pomt,  however,  the  prixedures  diverge.  Deliberate  plannuig  produces 
tlie  plan,  including  the  supported  CINC's  operation  plan,  supporting  plans  irom 
all  the  supporting  ClNCs  and  Service  org.unzations,  and  Lhe  tune-phased  toree 
and  deployment  database  (Tl’bDD)  The  ITFUD  then  becomes  the  basis  ot  the 
deployment  database  Continuing  activities  include  the  maintenance  (updating^ 
of  those  plans  and  databases 

Crisis-action  planning  differs  because  us  results  also  include  trixip  deployments 
and  perhaps  oinplovments,  so  its  fittli  stage  involves  detailed  execution 
planning  A  final  stage  can  include  tfie  movement,  staging,  and  maiiein  er  ot 
forces 

.As  the  figure  suggests,  crisis-action  planning  is  lielped  significantly  it  there  is  a 
completed  C^pLAN  that  can  be  adopted  or  adapted  during  course-oi-action 


8 


development  and  an  existing,  even  if  embr\’onic,  deployment  database.  If  those 
do  not  exist  for  a  particular  exigency,  then  even  an  outline  or  concept  plan  can 
help.  If  neither  exists,  it  is  called  a  "no-plan"  situation  and  crisis-action  planners 
must  create  both  the  plan  and  the  database.  Operation  Desert  Shield  reflected  an 
intermediate  case,  where  there  was  no  OPLA,NJ  or  database  from  the  deliberate- 
planning  process  that  could  be  directly  and  inunediately  used,  but  a  partial  plan 
existed  from  which  initial  information  could  quickly  be  abstracted.  The 
challenge  was  to  fill  out  and  execute  that  plan  quickly. 

Operation  Desert  Shield  covered  the  initial  planning  for  and  execution  o*  tlie 
mobilization  and  deployment  of  U.S.  forces  from  the  United  Slates  and  Europe, 
and  the  defensive  employment  of  those  forces  in  Saudi  Arabia.  In  this  report  vve 
focus  on  the  deployment  activities,  but  obviously  we  can  discuss  and  consider 
those  only  withm  the  overall  context.  The  United  States  deployed  forces  only 
because  it  felt  the  need  to  employ  them.  Many  units  needed  to  be  mobilized 
before  they  could  be  deployed  or  employed.  All  deployed  troops  and  equipment 
needed  to  be  resupphed.  Planning  procedures  necessarily  cover  the  full 
operation,  although,  as  we  will  see,  they  and  especially  their  computerized 
support  currently  focus  on  deployment. 


Deliberate  Planning 

To  put  ODS  in  perspective,  it  is  necessan.'  to  understand  both  dehberate  planning 
and  crisis-action  planning.  Deliberate  plannmg  logically  comes  first.  The  five 
phases  of  the  deUberate-planning  process  begin  when  a  theater  commander 
receives  a  task  assignment  and  end  when  an  OPLAN  with  supporting  plans  and 
TPFDD  have  been  approved  by  the  supported  CINC. 

An  OPLAN  Ls  a  description  of  the  CINC's  concept  of  operations  and  ide^'lifies 
the  forces  and  supplies  required  to  execute  the  plan.  It  includes  a  movement 
schedule  of  those  resources  into  the  theater.  Developing  an  OPLAN  requires 
much  time  and  effort  and  is  appropriate  only  in  selected  situations:  when  a 
hostile  situation  is  critical  to  U  national  security,  as  a  deterrent  to  an  enemy  in 
showing  U.S.  readiness  through  planning;  or  when  the  operation  is  expected  to 
tax  total  U.S.  capabilitv  in  forces,  supplies,  or  transportation.  In  less  serious 
situations,  the  plannmg  process  is  followed  only  through  the  development  of  tlie 
concept,  and  results  in  the  abbreviated  operation  plan  called  the  CONPLAN.^’ 


NhiTc  .ire  hasii.  differi'mi-.  brtworn  the  Ol’l-.-lN  and  CC1N.'’'.aN.  The  CH’t  .A.N  lullv  d('vel'lp^ 
liie  CINCS  mneept  ut  operation.*,,  llie  doeiiinentation  includes  annenes  that  desenhe  the  concept  and 
explain  the  ihcalcr-wide  suppt'rl  required  in  the  subcirdiiiate  tomniander  s  einpluvmer.t  plan  Tlie 
OI’L.AN  concentrates  on  dcplc,'ment  o*  resource,s  and  contain.s  a  1  Ti'l.lD.  The  Cl  ).N1’L.*\N  i.s  less 
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Phase  I — Initiation 

In  Phase  I,  the  CJCS  towards  the  planning  task  to  the  combatant  conunander 
(the  supported  CINC),  directs  him  to  produce  either  an  OPL.AJM  or  a  CONPLAN, 
and  apportions  major  forces  and  strategic  transportation  assets  for  hLs  planning. 

Phase  II — Concept  Development 

During  this  phase,  the  supported  CINC  derives  the  mission  from  the  assigned 
task.  He  issues  planning  guidance  to  his  staff  and  they  begm  to  collect  and 
analyze  information  concerning  the  enemy-  As  quickly  as  possible,  the  staff 
proposes  and  analyzes  alternative  courses  of  action  (COAs),  the  CLMC  -i  ^ects  the 
best  COA,  tind  the  staff  develops  and  documents  a  concept  of  operation.-.  By  the 
authority  of  the  CJCS,  the  Joint  Staff  reviews  the  concept  and  recommends 
approval  or  disapproval.  The  COA  is  a  statement  of  how  the  commander 
expects  to  conduct  the  operation  m  terms  of  deployment,  employment,  and 
support  of  the  apportioned  forces.  It  identifies  major  objectives  and  target  dates 
for  their  attainment.  If  the  task  assignment  is  to  produce  a  CONPLAN,  then  at 
the  end  of  Phase  II  the  concept  is  dcKumented  in  the  CONPLAN,  receives  final 
revie  .v  and  approval,  and  the  planning  process  is  tenrunated.  If  thie  task 
assignment  is  to  produce  cin  OPLAN,  planning  continues  into  the  next  phase. 

Phase  III — Plan  Development 

In  this  phase,  the  supported  CINC's  concept  of  operations  is  expanded  into  a 
complete  OPLAN.  During  the  initial  steps  of  this  phase,  the  subordinate 
commanders  in  unified  combatant  commands  (these  are  the  Service  Component 
Commanders  or  SCCs)  begin  developing  the  total  package  of  forces  required  for 
the  operation.  They  start  by  selecting  the  major  combat  forces  from  those 
apportioned  in  the  original  task-assigning  document.  Working  closely  with  the 
staffs  of  tfieir  respective  Service  headquarters,  other  supportmg  commanders, 
and  DoD  agencies,  the  SCCs  identify  required  support  forces  and  sustainment. 
Tile  supported  CINC  consolidates  each  component's  forces  and  supplies,  and 
details  the  phasing  of  those  movements  into  the  theater  of  operations.  Required 
intratheater  transportation  movements  arc  identified  and  assigned  to 
apportioned  intertheater  transportation,  to  CINC-controlled  theater 


dt'tailit)  in  dcxunuTiled  prcstnlalinn  of  tlic  ClN'C's  plan.  Computfr  support  is  not  ^'t-nerally  requirtd 
for  tho  CONPLAIvJ  since  detailed  support  requirements  need  not  be  calculated  and  strategic 
movements  are  not  simulated.  The  CONPLAN  does  not  generallv  mclude  the  detail  found  in 
OPLAN  annexes,  but  may  t.ave  sc-lected  annexes  and  a  TPFDD  if  the  CI.NC  so  directs 
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h  ansportation,  or  to  transportation  organic  to  the  subordinate  commands. 
Intertheater  movements  are  simulated  with  a  computer  model  until  the  CINC  is 
reasonably  confident  that  they  are  feasible  usmg  only  CJCS-apportioned 
transportation  assets.  During  the  later  steps  of  tfiLs  phase,  the  Services  replace 
hypotlietical  (notional)  combat  and  support  units  in  the  plan  with  references  to 
actual  units.  In  a  final  step,  USTR/\KSCOM  and  its  component  commands  (Air 
Mobility  Command  or  AMC,  Military  Sealift  Command  or  MSC,  or  Militarv' 
Traffic  Management  Commemd  or  MTMC)  use  more  sophisticated  computer 
models  to  again  simulate  the  intertheater  (and  sometimes  the  intratheater) 
movements  to  ensure  tliat  the  TPFDD  is  transportationally  feasible.  At  the  end  of 
this  process,  USTRANSCOM  copies  the  TPFDD  info  a  deplovment  database.' 


Phase  IV — Plan  Review 

The  ejes,  his  staff,  and  advisers  review  all  elements  of  the  plan  for  adequacy 
and  feasibilih'. 

Phase  V — Supporting  Plans 

Each  subordinate  and  supporting  commander  who  has  been  assigned  a  task  in 
the  supported  ClNC's  plan  now  prepares  a  supporting  plan  and  submits  it  to 
him  for  .review  and  approval.  When  all  supporting  plans  are  complete,  the 
ClNC's  plan  is  ready  for  implementation. 

A  continuing  task  is  then  to  keep  the  plan  up-to-date  and  ready  for 
implementaoon.  The  supported  CINC  specifies  how  often  maintenaiice  and 
updating  are  required.  Changes  m  sourcing,  unit  equipment,  location,  or  stale  cf 
unit  readmess  all  affect  the  plan,  since  they  may  change  the  amount  of  mateiiel 
to  be  deployed  or  the  port  of  embarkation  where  it  will  be  loaded.  All  members 
of  the  JPEC  share  in  responsibility  for  keepmg  the  deployment  database  current. 


Crisis-Action  Planning 

Crisis-action  planning  procedures  are  designed  to  be  used  by  the  JPEC  to  plan, 
deploy,  and  employ  U.S.  militai .  forces  m  time-sensitive  situations  such  as  m 
Operation  Desert  Shield.  As  shown  in  Figure  4,  the  ciisis-actiun  plannmg  system 


'  As  we  shall  see  in  the  next  section,  this  is  the  point  at  which  the  force  deployment  database 's 
transferred  from  the  JOPS  format  u.sr-d  bv  deliberate-planning  AIS  into  the  JDS  format  and  system 
used  by  US  I'KANsCD.M  and  the  TCCs 


is  divided  into  six  separate  phases,  each  with  a  definite  start,  and  finish,  and  with 
actions  to  be  performed  by  key  membeis  of  the  JPEC  community'. 

Phase  I — Situation  Development 

OrganLzarions  of  the  U.S.  government  routinely  monitor  world  events  for 
possible  security'  implications.  When  such  an  event  is  identified  it  is  reported  to 
the  National  Military  Command  Center  (NMCC)  and,  if  the  NCA  deem  it 
appropriate,  Crisis-Action  Procedures  (CAP)  are  initiated. 

In  this  first  phase,  the  focus  is  on  the  theater  CINC  who  will  be  responsible  for  all 
U.S.  military  action.  His  staff  reviews  OPLANs  and  CONPLANs  for  relevance. 

A  secure,  crisis-specific  teleconference  (electronic  mail  system)  Ls  established  to 
allow  rapid  exchange  of  information.  When  completed  the  CDSlC's  assessment  is 
submitted  to  the  CjCS  and  the  NCA. 

Phase  II — Crisis  Assessment 

Tnis  phase  emphasizes  information  gathering  and  the  review  of  available  options 
by  the  NCA.  They  and  the  CJCS  analyze  the  situation  to  determine  whether  a 
military  option  should  be  prepared  to  deal  w'ith  the  evolving  problem. 

The  NCA  identify  the  national  interests  at  stake;  the  national  objectives  related  to 
those  interests;  and  possible  diplomatic,  political,  economic,  and  military  options 
to  achieve  the  objectives.  They  may  decide  that  a  crisis  exists  and  that  military 
COAs  should  be  developed  by  the  CINC.  The  CJCS  assesses  the  situation  from 
the  military'  point  of  view  and  may  recommend  to  the  NCA  that  orders  be 
published  to  prepare  to  deploy  forces.  This  phase  ends  when  the  NCA  decide 
whether  or  not  to  have  mUitary  options  considered. 

Phase  III — Course  of  Action  Development 

Following  the  decision  of  the  NCA  to  develop  possible  military  solutions  to  the 
crisis,  the  CJCS  publishes  a  Warning  Order  giving  mitial  guidance  to  tlie  JPEC 
and  requesting  the  supported  CINC  to  recommend  a  COA  to  meet  the  situation. 
(In  a  fast-breaking  crisis  this  can  simply'  be  a  telephone  conference  with  a  follow- 
on  for-tlie-record  message  to  the  JPEC.) 

The  supported  CLNC  develops  COAs  with  the  help  of  subordinate  and 
supporting  commanders.  When  available,  existing  CONPLANs  md  OPLANs 
are  consulted  and  exusting  deployment  databases  are  used  to  develop  force  lists 
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and  support  packages.  The  Services  monitor  the  deplov^nent  piannmg  and 
assess  the  readiness  of  their  forces.  As  time  permits,  USTRANSCOM  reviews  the 
proposed  COAs  for  transportability  and  prepares  feasibility  estimates.  This 
phase  concludes  when  the  supported  CINC  releases  his  "Commander's 
Eshmate." 


Phase  IV — Course  of  Action  Selection 

In  this  phase,  the  CJCS  and  the  JS  review'  and  analyze  the  Commander's  Estimate 
and  present  the  COAs  in  order  of  priont)'  to  the  NCA  for  decision.  The 
supported  CINC  and  the  JPEC  conhnue  deployment  and  employment  plaruring. 

After  the  CJCS  and  his  staff  evaluate  the  COAs,  the  NCA  select  one  and  direct 
that  execution  planning  should  begin.  The  CJCS,  under  the  authority  of  the 
Secretary  of  Defense,  issues  an  Alert  Older  to  the  CEN’C.  He  may  also  issue  a 
Deployment  Preparation  Orde.  jr  Deplovment  Order. 

Phase  V — Execution  Planning 

The  supported  CINC  now'  transforms  the  NCA-selected  COA  into  an  operational 
order  (OPORD).  This  phase  encompasses  three  major  tasks: 

•  Execution  piannmg — developmg  the  OPORD  by  modih'ing  an  existing 
OPLAlN,  expanding  an  existing  CONPLAN,  or  building  it  from  scratch  when 
no  plan  exists. 

•  Force  preparation — selecting  the  actual  units  to  participate  in  the  planned 
operation  and  readying  them  for  deployment. 

•  Deployability  posture  reportmg — issuing  situation  reports  (51  PREPs) 
documentmg  the  early  attainment  of,  or  deviations  from,  specified 
deployability  postures. 

Emphasis  during  this  phase  rests  with  the  supported  CINC  and  his  subordinate 
and  supporting  commanders.  However,  other  JPEC  members  are  contributing 
also;  The  CJCS  monitors  the  development  of  tlie  ClNC's  OPORD  and  resolves 
shortfalls;  CINC  USTRANSCOM  coordinates  the  changes  to  the  forces  and  the 
strategic  lift  resulting  from  those  shortfalls;  the  TCCs  create  the  schedules  for  air 
and  sea  with  concentration  on  the  initial  increment  of  movements,  seven  days  by 
air  and  30  davs  bv  sealift. 
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ThLs  phase  ends  when  the  NCA  decide  to  execute  the  OPORD,  to  place  it  on 
hold,  or  to  seek  resolubon  by  other  means. 

Phase  VI — Execution 

Execution  begins  with  the  NCA  decision  to  choose  tlie  militan,'  option  and 
execute  the  OPORD.  The  Secretary  of  Defense  then  authorizes  the  CJCS  to  issue 
an  Execute  Order  directing  the  CINC  to  carry  out  the  OPORD.  In  a  fast- 
developing  crisis,  the  Execute  Order  could  be  the  first  communication  of  record 
generated  by  the  CJCS  and  might  even  be  preceded  by  a  voice  announcement. 

The  Execute  Order  defines  C-day  (the  day  on  which  the  first  movements  will 
begin)  and  the  resource  aUocation  and  dmects  execi  tion  of  the  OPORD.  The 
CJCS  monitors  deployment  and  employment  of  forces,  directs  the  resolution  of 
conflicts,  and  assesses  the  achievement  of  objectives.  The  supported  CINC 
carries  out  tf  e  Execute  Order,  transmitting  his  own  guidance  to  subordinates  and 
supportmg  commanders.  Those  commanders  execute  their  CIKC-directcd 
OPORDs,  revalidate  the  sourcing  and  scheduling  of  units,  report  movements  of 
organic  lift,  and  report  deployment  movements.  Execution  continues  until  the 
operation  is  complete  or  canceled. 


Summary 

This  was  the  status  of  deployment-planning  procedures  at  the  start  of  OD5.  For 
major  contingencies  the  deliberate-plemning  process  was  expected  to  slowly  and 
laboriously  produce  detailed  OPLANs  and  TPFDDs.  In  crisis-action  situations, 
officials  were  expected  either  to  pull  a  relevant  OPLAN  and  TPFDD  from  the 
shelf  and  update  them  for  use  or  to  quicklv  and  efficiently  w  ork  through  a 
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Figure  5 — Planning  and  Practice  Have  Been  Linear 


compressed  version  of  the  deliberate-planning  process,  but  in  days,  not  months. 
In  either  case,  planning  would  be  complete  and  a  detailed  (and  stable) 
desenption  of  the  content  and  sequence  of  the  deploymient  would  be  generated 
before  anyone  began  to  execute  the  deployment.  Figure  5  illustrates  this  process. 

Tractice  and  exercises  went  by  that  book.  Deliberate-plarining  activities  were 
long  and  involved.  Cnsis-achon  activihes,  when  they  occurred,  were  short, 
intense,  and  involved  orviy  a  few  elements  of  the  rapid-deployment  forces. 
Deployment  planning  began  with  and  centered  on  a  stable  TPFDD.  Deployment 
exercises  utilized  that  stable  TPFDD,  seldom  acknowledging  uncertainties  tliat 
could  cause  changes  in,  for  example,  the  CINC's  priorities,  the  amount  of 
equipment  that  urats  brought  to  their  ports  of  embarkation  (POEs),  changes  in 
the  availabilitv  of  transport  ships  and  planes,  or  similar  items. 
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3.  Computerized  Support 


Computerized  support  for  deployment  plaruung  consists  of  hardware  and 
software  designed  for  and  sometimes  by  the  jomt  community  and  the  Services. 
Jomt  systems  center  on  the  Worldwide  Military-  Command  and  Control  System 
(VVWMCCS)  and  its  major  set  of  software — the  Joint  Operation  Planning  and 
Execution  System  (JOPES).  JOPES  runs  on  V\'W'MCCS  hardware  at  30-some  sites 
throughout  the  world;  sites  are  interconnected  through  the  VVWMCCS 
Intercomputer  Network  (WIN).  The  VVWMCCS'  primary’  mission  is  to  support 
the  NCA;  secondarily  it  supports  the  Services  and  other  DoD  agencies. 

■Army  planning  is  supported  by  the  Army  VVWMCCS  System  (AWIS)  program 
which  provides  interfaces  between  JOPES  and  Army-specific  systems  at  eight 
Army  VVWMCCS  sites.  This  mcludes  several  service-specific  systems  hosted  at 
the  Forces  Command  Headquarters  WVVMCCS  site  specifically  supporting 
deployments.  The  AWIS  program,  has  two  missions:  supporting  the  Army's  use 
of,  and  contribution  to,  the  joint  systems,  and  supporting  the  Army's  umque 
strategic  command  and  control  mission. 

These  are  all  evolving  systems  in  which  older  technology  and  capabilities  are 
continually  being  replaced  and  updated.  The  systems  and  some  of  theu- 
interactions  during  the  ODS  period  are  bnefly  described  m  the  followmg  section. 
Readers  desiring  more  information  should  consult  the  appendixes  and  the 
government  documents  referenced  therein. 


WWMCCS 

Computers  have  aided  military'  planning  and  command  and  control  for  many 
years,  and  for  just  as  long  they  have  created  problems  and  confusion.  As  earlv  as 
the  1960s,  it  had  become  apparent  that  different  types  of  computers,  mcompahble 
software  programs,  and  inconsistent  plannmg  procedures  and  documentation 
were  making  it  difficult  for  commands  and  commanders  to  communicate 
effectively.  Work  soon  began  on  an  integrated  planning  system  to  address  those 
problems,  and  by  1973  some  35  WVVMCCS  sites  had  been  set  up  and  furnished 
With  Honeywell  6000  computers.  In  the  early  1980s,  Honeywell  upgraded  the 
computers  and  the  operahng  system.  This  equipment  remams  the  "standard" 
ADP  support  for  joint  operations  plannmg  and  execution.  Since  the  late  1980s,  it 
has  been  supplemented  by  IBM-compatible  personal  computers  used  as 


terminals  and  low-level  workstations.  Current  modernization  efforts  seek  to 
provide  more  powerful  workstations  and  lessen  dependence  on  the  aging 
mainframes. 

The  WWTvICCS  Intercomputer  Netrvork  links  users  around  the  world.  Using 
WIN,  planners  can  communicate  wiLh  other  users,  review  and  update  data  from 
other  WW'MCCS  locations,  and  transfer  data  between  computers.  Land  line  and 
satellite  corrections  permit  real-time  top  secret  communications.  With  proper 
permissions,  users  can  log  onto  remote  host  WWMCC5  computers  much  the 
same  as  they  log  onto  their  local  computer.  WIN  teleconferencing  allows  many 
WWMCCS  sites  to  confer  and  exchange  textual  information  simultaneously. 

JOPS,  JDS,  and  JOPES 

The  Joint  Operation  Planning  and  Execution  System  provides  the  automated 
support  for  major  deplo\ment-plannmg  achvilies.  JOPES  at  this  stage  of  its 
development,  however,  is  essentially  a  patched-together  version  of  two  rather 
dated  systems:  the  Joint  Operation  Planning  System  and  the  Joint  Deployment 
System.  In  order  to  understand  JOPES — its  problems  and  limitahons  as  well  as 
its  potential — it  is  necessary  to  understand  JOPS  and  JE>S. 

JOPS 

JOPS  is  an  ordered  and  comprehensive  set  of  procedures  for  translating  an 
assigned  task  into  a  plan  of  operations.  "It  is  a  WWMCCS  standard  computer- 
based  system  used  in  the  deliberate-planning  process  by  members  of  the  JPEC  to 
develop,  analyze,  refme,  review,  and  mamtain  an  OPLAN  and  to  prepare 
supporting  plans.  Standard  files,  formats,  md  applicahon  programs  provide 
support  for  force  planning,  determination  of  nonunit-related  cargo  emd  personnel 
movement  requirements,  transportation  feasibility  estimation,  logistic  factors, 
civil  engineering  support,  and  medical  planning."* 

The  main  purpose  of  JOPS  is  to  assist  in  the  plan  development  phase  (Phase  III) 
of  deliberate  planning.  Sen'ice  planners  build  the  force  list,  calculate  the  flow  of 
nonunit  cargo  and  personnel,  and  complete  specialized  planning,  such  as  civil 
engineering  and  medical  support.  They  produce  tlie  mitial  version  of  the 
TPFDD.  The  CINC's  planners  then  use  JOPS  to  test  the  gross  transportation 
feasibility  of  the  TPFDD  and  to  revise  the  database  after  the  deliberate  planning 

*JorS  Volume  lU,  S,M-.524-85,  p  1-2. 
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refinement  conferences.^  lOPS  provides  automated  aid  to  strategic  deployment 
plannmg  and  limited  sustainment  planning,  but  provides  no  aid  to  mobilitv  or 
employment  planning. 

Here  we  will  summarize  the  several  steps  of  the  plan-development  phase  tliat  are 
important  in  understanding  the  Army  experiences  reported  in  the  followmg 
sections.  The  entire  phase  is  discussed  at  greater  length  in  Appendex  A. 

Force  Planning.  In  force  planning  the  Service  component  commanders  identify 
the  forces  needed  to  accomplish  the  CINC's  concept  of  operations  and  indicate 
how  they  should  be  phased  mto  the  theater.  Each  commander  develops  his  own 
notional  force  list  composed  of  combat,  combat  support  (CS),  and  combat  service 
support  (CSS)  forces,  usmg  Ser\'ice  planiung  documents.-^  The  collection  of  the 
components'  force  lists  is  merged  by  the  CINC's  staff  and,  when  he  approves, 
becomes  the  CINC's  consolidated  force  list.  The  database  becomes  the  OPL,‘\N 
TPFDD. 

Support  Planning.  In  support  planning,  the  Service  commanders  identify  the 
quantities  of  supplies,  equipment,  and  replacement  personnel  as  w  ell  as  civil 
engmeermg,  medical,  and  fuel-related  materials  required  to  sustain  the  forces 
identified  in  force  planning.  Primary  concern  at  this  time  is  with  the  amount  of 
strategic  Lift  that  will  be  needed  to  move  the  support  requirements. 

The  calculations  are  generally  made  by  the  SCCs,  who  refer  to  Service  plamiing 
guidelmes  and  Service  doctrine,  but  it  is  also  possible  for  the  supported  CINC  to 
perform  the  calculations  using  component-supplied  force  lists  and  Serv  ice 
plannmg  factors. 

Transportation  Planning.  After  all  the  nominal  force  and  non-unit  record  entries 
are  entered  mto  the  TPFDD,  the  Services  "source"  the  unit  records;  that  is,  thev 


■^lOPS  allows  for  four  levels  of  data.  Level  1,  aggregated  cargo  detail,  expresses  the  total  number 
of  passengers  (PAX)  and  total  short  tons  (STONs)  and/or  total  measurement  toas  (MTONs).  TTiis 
level  faalitates  gross  movement  estimates  and  overall  order-of-magiutude  ludgments. 

Level  2,  summary  cargo  detail,  expresses  the  number  of  PAX  and  STONS/MTON5  of  bulk, 
oversized,  outsized,  and  non-air  transportable  cargo.  Ibis  supports  aircraft  scheduling  and  allows 
determination  of  aircraft  tvpes  required. 

l,evel  ?,  detail  by  category  of  cargo,  expresses  square  feet  and  STCNSs /MTONs  of  cargo 
identified  within  a  designated  three  position  ccxfe  (Cargo  Category  Code)  which  delineates  general 
cargo  characteristics,  e  g  ,  wheel  vehicles,  track  vehicles,  container  compatibilitv,  unit  equipment,  etc 
This  level  supports  aircraft  schedulmg  when  summary  data  are  not  present  and  allows  more  detail 
for  planning  transportation  lift  asset  requirements 

Level  4,  detail  by  type  equipment,  expresses  quantity  of  type  equipment  to  include  length, 
width,  height,  pieces,  square  feet,  and  STONs/MTONs.  e  g  ,  Line  Item  Number,  Truck  Cargo  2  1/2 
Ton,  ti  pii-ces,  26?  x  95  x  81,  17?  sq  ft.,  S  .'i  STONs.  29  5  MTClNs  This  level  is  used  bv  the  Supported 
Commander  to  tailor  units  to  mi.ssion  requirements. 

■  For  example,  the  Army  uses  the  four  volume  Anny  Mcibilization  Operations  Planning  Systems 
(AMOPS)  document 
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replace  tlie  force-type  records  with  records  tied  to  actual  units  with  actual 
cargoes^  llien  the  initial  transportation  planning  is  done  by  the  supported 
CINC.  His  planners  simulate  the  intertlieater  mo%’ement  of  the  troops  and 
cargoes  now  on  the  force  list  using  the  Transportation  Feasibilit)’  Estimator 
(TFE),  a  JOPS  application.  The  goal  is  to  tailor  the  sequenced  force  list  so  Uiat  all 
units  can  arrive  according  to  the  CINC's  desired  time  lines,  using  only  the 
intertheater  transport  capability  that  was  allocated  to  this  plan,  by  the  CJCS.  Tliis 
is  typically  difficult  because  transport  is  almost  always  limited.  Transportation 
plarming  is  an  iterative  process:  WTien  TFE  indicates  that  the  currently 
sequenced  forces  and  non-unit  supplies  cannot  be  moved  in  time,  planners 
identify  the  problems,  evaluate  the  impact  on  the  overall  plan,  mcorporate 
solutions,  and  tlien  run  tlie  simulation  agam. 

Shortfall  Identification.  This  step  focuses  on  identifvmg  and  resolving 
transportation  shortfalls  highlighted  by  the  TFE  deployment  simulation.  The 
TFE  identifies  the  late  arrival  shortfalls  and  the  reasons  for  them,  such  as 
shortage  of  lift  resources,  overloaded  mobility  support  facihhes,  excessive 
requirements  for  intratheater  lift,  etc.  Planners  identih'  unresolved  shortfalls  for 
corrective  actions  by  higher-level  decisiorunakers  or  those  that  must  be  resolved 
with  other  commanders  bv  compromise  or  mutual  agreement.  The  CINC  alone 
approves  changes  that  affect  the  concept  of  operations  or  the  concept  of  support. 

Transportation  Feasibility  Analysis.  More  formal  analysis  of  transportahon 
requirements  and  capabilities  occurs  in  this  step.  USTRANSCOM  and  its 
transportation  component  commands  use  their  more  sophisticated  mobihty 
simulation  models  to  estimate  when  pickups  and  arrivals  will  occur,  how  many 
ships  and  planes  will  be  needed,  the  congestion  to  be  expected  at  port:,  elv. 
Problems  with  cargoes  are  referred  back  to  the  CINC  for  resolution,  often  at  a 
transportation  refmement  conference.  If  all  problems  can  be  resolved,  the  output 
of  thus  step  IS  termed  a  "transportationally  feasible"  TPFDD. 

To  summarize,  JOPS  primarily  assists  m  the  plan  development  phase  (Phase  111) 
o‘  deliberate  planning.  Sen  ice  planners  build  the  force  list,  calculate  the  flow  of 
nonunit  cargo  and  personnel,  complete  specialized  plannmg,  and  assist  the  CINC 
in  constructing  the  TPFDD.  A  completed  deliberate-planning  process  outputs  an 
OPLAN,  a  scries  of  supportmg  plans,  and  a  transportationally  feasible  TPFDD 


^Before  lr,ins(niri.nn’n  pUiiiniiik;  tn'>;ins,  the  mtnponenl  pl.inners  will  attempt  to  designate-  as 
many  acUial  uniis  a>  llu’v  can  U'  r^’placc  tiic  tvpe  units  m  tht’  kute  list.  This  improves  the  accuracy  of 
the  transpKiii.Ttu'i'.  rcquircnu’nis  irnpli(\l  hv  the  force  list.  In  the  Army,  sourcinp,  begins  with  the  force 
selection  by  I  OKSC’OM 
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that  can  be  converted  into  JDS  format  and  used  in  deployment  schedulmg  and 
execution 


JDS 

As  a  further  step  in  improving  depk.\Tnent  capabilities,  the  Office  of  the  Joint 
Chiefs  of  Staff  in  1979  created  the  Jouit  Deployment  Agency  and  directed 
development  of  an  automated  system  to  support  deployment  plannmg  and 
execution.''  Tlie  result  was  tlie  Jomt  Deployment  Svstem  for  crisis-achon 
planning  and  execution. 

JDS  is  a  system  of  people,  procedures,  communications  capabilities,  and  ADP 
equipment,  it  is  part  of  VVVVMCCS  and  interfaces  with  other  command  and 
control  systems.  JDS  is  built  on  a  distributed  database  architecture  with  network 
control  at  Scott  Air  Force  Base,  Illmois.  The  JDS  database  is  the  primary 
repository  of  deployment-related  mformation  and  can  contain: 

•  Narrative  information  on  plan  concept,  scope  and  status; 

•  TPFDDs  that  are  either  available  from  an  existing  plan,  built  Ime-by-line  with 
force  and  cargo  records,  built  with  force  modules,  or  created  by  a 
combination  of  these  methtxls;  and 

•  Notional  cargo  data  that  may  be  refined  and  updated;  actual  unit  data  that 
are  sourced;  and  individual  entries  of  cargo  increments,  personnel 
increments,  and  unit-related  data  that  may  be  updated  and  refined  to 
improve  visibihtx'  as  tlie  situation  changes. 

Ihe  JDS  lb  designed  to  allow  the  tmie-phased  force  and  deployment  data  output 
from  the  planning  process  to  be  consolidated,  combined  with  information  from 
other  transport- related  databases,  and  viewed  from  vanous  angles,  facilitating 
tlie  validation,  schedulmg,  and  tracking  of  passengers  and  cargoes.  In  particular, 
it  allows  the  TCCs  to  match  movement  requirements  against  their  own  dymamic 
data  concemmg  ship,  aircraft,  and  crew  availabilities  and  rouhngs.  It  allows  ui  it 
and  torce  commanders  to  view  movement-requirements  records  and  validate 
(promLse)  that  their  movement  packages  will  show  up  at  the  assigned  POEs  on 
the  assigned  dates  with  (only)  the  mdicated  ainounb  of  cargo.  It  allows  unit  and 
force  commanders,  as  well  as  the  JCS  and  the  NCA,  to  follow  the  departures, 
movements,  and  arrivals  of  the  troops,  equipm.cnt,  and  supplies. 


^Joint  Pvploynu'ni  ..X^ence-  (JP-'X)  .iclivities  were  incorporated  into  L'STRANSCOM  when  itial 
f^rganizjlion  was  e>tabiishL*d. 
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Ihe  ]li)S  IS  rather  rigid,  iiowever,  and  changes  and  real-world  events  cause 
problems,  especiall\'  durmg  execution.  As  we  will  see  in  Sections  4  mid  5,  !or 
example,  when  a  unit  is  not  ready  to  deploy  on  the  planned  date,  when  an 
aircraft  or  ship  breaks  down  and  another  must  be  substituted,  or  when  only  part 
of  a  planned  load  is  actually  shipped,  the  database  cannot  be  adjusted.  Tlie  only 
way  to  record  the  actual  event  is  to  go  back  and  change  the  planned  event  to 
represent  the  actual  occurrence.  Tnat  is,  except  for  certain  events  like  time  of 
departure  and  time  of  arrival,  the  database  cannot  show  discrepancies  between 
planned  ei  ents  and  actuals  Tlius,  its  utility  for  tracking  units,  preparmg  to  meet 
aircraft,  preparing  to  receive  arric  mg  units,  and  other  real-time  actions  is  not  all 
that  might  be  desired. 

JOPES 

Some  of  the  contrasts  between  JOPS  and  IDS,  as  well  as  some  of  the  similarities, 
should  now  be  apparent.  JOl’S  contams  applications,  databases,  and  procedures 
to  support  deliberate  j'lanning  It  primarily  aids  tire  supported  CINC — the 
combatant  coinniander — and  his  Ser\  ice  subordinate  comm.mdcrs  Emphasis  ls 
on  plannmg  lorce  employment  and  definmg  the  desired  flow  of  forces  into  the 
theater.  Primary  outputs  are  the  OPLAN,  a  series  of  supporting  plans,  and  a 
TPFDD. 

JDS,  on  the  other  hand,  texuses  on  deployment,  primarily  supporting 
USTRANSCOM  and  the  TCCs-  It  accepts  a  JOPS-created  TPFDD  as  input, 
matches  it  agauist  similarly  detailed  infomiation  on  aircraft  and  ship 
availabilities  and  capabilities,  and  assists  planners  in  produemg  a  complete 
movement  schedule  with  cargoes  matched  up  with  vehicles  on  particular  days 
and  routes,  both  JDS  and  JOPS  are  detailed,  bottoms-up  systems,  and  both  can 
use  either  notional  or  actual  cargo  information. 

Both  systems  were  designed  to  aid  planners  m  the  enomiously  complex  task  of 
developmg  force  and  deployment  plans.  However,  JOl’S  and  JDS  were 
developed  independently  and  have  mcompatible  file  structures;  data  sharing 
between  them  has  always  been  difficult  and  laborious.'’  A  new  system  to 
integrate  dephn  inent  plannmg  and  deployment  execution  was  needed.  Since 
1981,  the  Joint  Operation  Pluming  and  Execution  System  (JOPES)  has  been 
attemptmg  to  build  >uch  a  system  by  modemizmg,  extendmg,  and  combmmg  the 
functionality  ot  jOl’S  and  JDS. 


'’Lvo.';'!  Ill  :.  ovjr>i.',  for  Iho  traniiiT  of  thi-  IPirrD  from  JOPS  to  IDS 


The  mam  problem,  of  course,  has  been  the  difference  in  file  structures.  Data  files 
used  or  produced  by  an  application  program  on  one  svstem  could  not  be  used  bv 
an  application  program  on  the  other.  Originally,  the  only  bndge  between  the 
two  was  a  program  that  converted  JOPS  TPFDDs  into  a  format  recognizable  by 
JDS  software.  That  allowed  the  JOPS-created  deployment  movement 
requirements  to  be  made  available  through  V\T\'  to  the  jPEC  so  that,  in  crisis 
plarming,  they  could  quickly  be  used  as  the  starting  point  from  which  to  develop 
an  OPORD.  Plans  call  for  developing  a  bridge  between  the  two  systems  that  will 
c\'entuallv  evolve  into  a  truly  integrated  system  of  data  and  applications.  But  as 
of  this  writmg — and.  more  importantly,  during  all  of  ODS — JOPS  and  JDS 
remamed  essentially  separate  systems. 

JOPES  Version  1,  installed  in  November  1989,  offered  a  high  -level,  loosely 
mtegrated  interface  to  the  JOPS  and  JDS  subsystems.  It  allowed  a  user  to  access 
either  JOPS  or  JDS  applications  witliout  exiting  one  subsystem  to  enter  the  other 
subsystem. 

JOPES  Version  2  was  installed  in  April  1990  and  supported  the  beginnmgs  of 
Operation  Desert  Shield.  It  offered  three  mam  improvements  over  Version  1. 
Fust,  a  new  mterface  allowed  users  to  run  several  JOPS  applications  using  JDS 
data  and  then  translate  the  JOPS  output  back  mto  JDS  format.  Second,  an 
mterface  processor  improved  data  distnbution  handi  ng.  Third,  it  enhanced  the 
ad  hcK  data  retrieval  capability. 

JOPES  Version  3  was  installed  in  December  1990,  during  ODS.  It  agam  offered 
three  enhancements:  first,  the  implementation  of  an  interface  developed  early  in 
ODS  from  AMC's  Global  Decision  Support  System  to  JOPES;  second,  a  fix 
allowing  users  to  recover  lost  TPFDD  records  by  retnevmg  information  from  the 
database  transaction  log;  third,  the  ability  to  generate  reports  detailing  database 
updates. 

In  bummary ,  during  ODS  the  JOPES  consisted  essentially  of  'ne  then-current 
versions  of  JOPS  and  JDS  patched  together  under  a  common  user  mterface.  Thus 
was  in  great  contradiction  to  the  public  perception  of  JOPES.  JOPES  had  been 
touted  for  years  by  its  supporters  as  the  .system  Uiat  would  (eventually)  integrate 
JOPS  and  JDS  and  plarming  and  execution.  Tliis  disconnection,  illustrated  m 
Figure  6,  made  it  extremely  difficult  for  commanders  as  well  as  planners  to  know 
what  they  could  or  should  expect  from  the  jomt  plannmg  support  sy.stems. 

Some  of  the  later  versions  and  plans  for  JOPES  are  described  in  Appendix  A. 
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Figure  6 — JOPES  Immature  but  Highly  Touted  in  1990-1991 


Army  Systems 

As  part  of  the  Joint  community,  the  Anny  follows  Joint  planning  procedures,  but 
it  also  relies  on  a  number  of  sen.'ice-unique  systems  to  assist  in  planning  and 
execution.  Department  of  the  Army  guidance  for  mobilization  and  deployment 
IS  established  by  the  Army  Mobilization  and  Operation  Planning  System 
(AMOPS).  The  Forces  Command  Mobilization  and  Deployment  Planning 
System  (FORMDEPS)  establishes  the  Forces  Command  mobilizahon  and 
deployment  policy. 

Forces  Command  (FORSCOM)  has  primary  responsibility  for  (1)  maintaining 
readiness  and  cargo  data  to  support  planning  for  mobilization  and  deployment, 
and  (2)  interfacing  the  Army  components  with  the  JPEC  tJirougli  JOPES.  In 
crisis-action  plaruiing,  FORSCOM's  tasks  include  participation  m  Army  combat 
unit  sourcing;  responsibility  m  coordination  with  Army  component  commanders 
for  sourcing  of  combat  support  and  combat  service  support  units;  participation  in 
time-phasing  and  transportation  planning;  responsibility  for  vabdation  of  Army 
planning  requirements;  and  responsibility  for  developing  timc-phasuig  of 
reserve  units  into  mobilization  stations  to  meet  departure  dates  from  those 
stations. 

Figure  7  shows  the  Amiy  planning  s\  >;cms  interface  to  JOPES  (and  each  other)  at 
the  WVVMCCS  FORSCOM  site  at  For:  McPherson.' 

The  Army  VN^VMCCS  Information  System  (AVVTS)  provides  information- 
processing  capabilities  for  planning  and  execution  at  eight  Army-suppoited 
WWMCCS  sites:  Forces  Command;  U.S  European  Command;  Army  component, 
U.S.  European  Command;  U.S.  Southern  Command,  Militar}’  Traffic 


'JOPES  and  'he  othur  loint  .systems  also  inlerlaic  with  Air  Force  and  Navv  AlSs  as  well  as  with 
those  of  the  ICCs  lliis  report  considers  only  the  joint  systems  and  the  Army-sj>ecific  systems 
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Figure  " — FORSCOM  VVWMCCS  Site  Showing  Army  AIS  Interfaces  to  JOPES 


Management  Command;  Army  component,  U.S.  Pacific  Command; 
Headquarters,  Department  of  the  Army;  and  the  Army  War  College.  AWIS 
provides  the  Army  with  (1)  WWMCCS  equipment,  (2)  centralized  software 
development  for  all  Army  strategic  command  and  control  products  as 
determined  by  the  JOPES  functional  model,  and  (3)  negotiations  and  support  for 
interfaces  between  Arm y_ strategic  C2  systenns  and  JOPES. 

The  evolving  AWIS  software  products  are  not  intended  to  duplicate  Joint  or 
Army  AIS  software  functionality,  but  to  complement,  supplement,  and 
implement  JOPES  in  those  areas  where  JOPES  software  does  not  meet  Army 
requirements.  Several  Army  AISs  appear  prominently  in  the  follow'mg  sections 
and  are  introduced  in  the  following  list.®  AWIS  program  plans  and  details  on  the 
major  Aimy  deployment-related  AISs  can  be  found  in  Appendix  B. 

DEMSTAT — The  Deployment,  Employment,  and  Mobilization  Status  System 
provides  CONUS-ba.scd  Army  installations  with  simplified  and  common 
access  to  information  from  Joint  and  Armv-specific  planning  systems: 

JOPES,  COMPASS  fComputerized  Movement  Planning  and  Status  System), 


defiiiiliorv.  wen*  taken  frnm  FORSCC.M  AlotiUzalion  an;!  Dcplai/mm:  I’lanr.in;  Susicm 
tFOR,MU£PSi,  Volume  V],  June  15,  IWl. 
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SORTS  (Status  of  Resources  and  Training  System),  etc.  It  provides  a  common 
interface  to  its  database,  allowing  the  installations  to  retneve/read 
preformatted  data  reports  but  not  permitting  them  to  du-ectly  make  changes. 

COMPASS — The  Computerized  Movement  Planning  and  Status  System 

maintains  Unit  Movement  Data  (UMD)  and  provides  the  Automated  Unit 
Equipment  List  (AUEL).  The  UMD,  a  listing  of  unit  equipment  by  pieces, 
weight,  and  cube,  are  reported  by  Army  units,  collected  here,  and  used  to 
determine  treinsportation  lift  requirements.  COMPASS  also  contains  notional 
Table  of  Equipment  (TOE)  data  for  use  in  tlie  earlier  stages  of  planning. 

These  are  in  Type-Unit  Characteristics  (TUCHA)  files. 

TC-ACCIS — The  Transportahon  Coordinator's  Automated  Command  and 
Control  Information  System  provides  the  installation  and  units  (down  to 
battalions  and  separate  companies)  with  the  capability  to  create,  update,  or 
modify  unit  movement  requirements  data,  and  to  produce  the  necessary 
transportation  documentation  and  reports  using  interactive  termmals  and 
application  programs. 

MSPS — The  Mobilization  Station  Planning  System  .'c  -gned  to  support 

mobilization  station  plaiuiing  of  both  active  ano  erve  comp  lent  units 
based  on  JOPES  uiforination.  It  iiiainlaiiis  and  displays  mobilit  'lion  and 
deployment  planning  information. 

SORTS — The  Status  of  Resources  and  Training  System  is  a  joint  data  system 
detailing  the  readiness  of  units  of  all  the  Services.  It  is  updated  once  a  day. 
FORSCOM  (cind  other  WWMCCS  users)  rely  on  SORTS  for  current 
information  concerning  tlic  readiness  and  training  of  units. 


Summary 

Computerized  support  for  deployment  planning  includes  both  Joint  and  Serv'icc- 
specific  sy'stems.  Joint  systems  center  on  the  WWMCCS  and  its  major  set  of 
software,  the  JOPES.  JOPES  runs  on  WWMCCS  hardware  at  30-some  sites 
throughout  the  world  intercormected  through  the  WIN.  WWTdCCS  and  JOPES' 
primary  mission  is  to  support  the  NCA;  secondarily  they  support  the  Services 
and  other  DoD  agencies.  Army  planning  centers  on  the  AW'IS  program,  which 
provides  interconnections  with  the  Joint  systems.  AWIS  supports  the  Army's  use 
of,  and  contribution  to,  the  Joint  systems,  as  well  as  the  Army's  unique  strategic 
command  and  control  mission.  Current  Army  concerns  center  on  how  to 
develop  these  systems  concurrently  while  both  maintaining  necessary  interfaces 
and  increasing  their  interoperabilib/. 
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The  Joint  and  the  Army-specific  deployment  AISs  all  support  the  generation  of 
OPLANs,  supporting  plans,  TPFDDs,  OPORDs,  and  deployment  databases.  In 
deliberate-planning  situations,  sufficient  time  is  usually  available  to  use  the 
systems — including  the  applicahons  and  the  reference  files — effechvely.  Crisis 
situations,  on  the  otlier  hand,  require  that  much  the  same  job — creating  a  COA,  a 
TPFDD,  and  then  a  deployment  database — be  accomplished  more  quickly,  and 
that  the  plans  be  executed.  This  places  stress  on  the  systems. 

JOPES  IS  attempting  to  integrate  the  planning  and  execution  of  deployments  (see 
Figure  8),  but  currently  it  relies  almost  completely  on  JOPS  and  JDS  capabilities. 
Like  those  .‘.ystems,  JOPES  is  a  detailed,  bottoms-up  system  that  can  use  either 
notional  or  specific  cargo  information;  like  the  JDS,  JOPES  is  awkward  in 
execution.  Designed  primarily  to  serve  the  NCA  and  the  CJCS,  it  is  also  the  only 
current  conduit  for  much  of  the  detailed  cargo  and  movement  information 
needed  bv  force  commanders  and  transportation  managers. 

.•\t  this  point  a  word  of  caution  is  needed.  Discussions  of  computerized  support 
systems  often  imply  that  those  systems  do  or  will  represent  the  major  or  even  the 
exclusive  means  of  communications  among  users.  That  is  not  only  untrue  in 
general,  but  it  is  especially  untrue  for  the  deployment  community  and  for  OC>S. 
Figure  9  illustrates  the  point.  The  JPEC  have  available  and  use  a  variety'  of 
communicc  tion  channels,  including  face-to-face  discussions  around  a  table  or 
desk.*^  Some  channels  are  (or  can  be)  highly  classified,  others  less  so.  Some 


Planning  and  execution 


Figure  S— JOPES  Integrates  the  Planning  and  Execution  of  Deployments 
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rhi'-Sf  chaiuu'b  and  thi ,  figure  arc  discussed  further  in  Appendix  A- 


JOPES  SYSTEM  OPERATION 


SOURCE.  Joint  Operat'on  Planning  and  Exanulinn  System  iJOPES)  General  Reference — 
Volume  1,  User's  Manual,  CSM  UM  339-90  (Revised),  Nov.  16,  1990,  Joini  Data  Systems 
Support  Center,  Defense  Communications  Agency. 

Figure  9 — Deployment  Communications 

channels  are  immediate  and  generate  instant  feedback,  others  are  slow  and 
uncertain.  VVe  will  see  in  the  next  section  that  although  many  ODS  data  flows 
txrcurred  through  the  VVTN,  others  used  less  secure  or  even  unclassified  channels. 
Much  of  the  text  traffic  and  summar)'-level  data  transfers  occurred  through  WIN 
teleconterences.  Many  of  the  shorter  and  more  time-urgent  communications 
were  by  secure  telephone. 

This  concludes  our  descriptions  of  the  deployment  planning  and  execution 
procedures  and  support  systems  existing  at  the  start  of  ODS.  The  next  section 
describes  how  ODS  violated  most  of  the  deplo\Tnent-planning  rules;  Troops 
began  to  deploy  almost  immediately  "without  a  TI’FDD";  and  the  majority  of  the 
planners  were  so  busy  coping  with  execution  details  needed  for  the  following 
dav  or  tw'o  that  Lhev  could  gi\'e  little  time  (or  thought)  to  looking  further  ahead 
and  doing  unit-  or  force-level  planning. 
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4.  Operation  Desert  Shield 


Operation  Desert  Shield  did  not  follow  th*.-  book.  Instead,  it  presented  planners 
with  the  urgent  need  for  the  immediate  deployment  of  a  sizable  force  under  a 
scenario  for  which  they  had  no  completed  OPLAN  or  TPFDD.  Planners  had  to 
improvise  and  to  build,  in  real  time,  an  employment  plan  and  a  deployment  plan 
at  the  same  time  that  they  were  deploying  initial  units.  As  it  turned  out,  because 
little  offensive  action  was  directed  against  our  forces,  ODS  resulted  in  badly 
needed  large-scale  testing  of  the  U.5.  deployment  planning  and  execution 
s  items. 


This  section  begins  with  a  short  description  of  the  status  of  deployment  plans  for 
the  U.S.  Central  Command's  area  of  responsibibty  as  those  plans  existed  late  in 
July  1990,  just  prior  to  the  crisis.  It  then  documents  m  as  much  detail  as  possible 
the  operadons  of  the  major  organizadons,  units,  and  systems  as  they  responded 
to  the  crisis,  first  by  simultaneously  planning  and  executing  the  deployment  of 
the  initial  defensively  oriented  forces,  and  then  more  deliberately  deploying  the 
Phase  II  (offensive-enabling)  forces. 

Figure  10  summarizes  the  timelines  for  Operations  Desert  Shield  and  Desert 
Storm.  On  August  2, 1990,  Iraqi  troops  attacked  Kuwait.  Crisis-action  planning 
began  immediately.  The  initial  order  to  deploy  combat  forces  to  the  Persian  Gulf 
was  issued  on  August  6.,  USCENTCOM  began  to  deploy  its  combat  forces  on 
August  7,  marking  C-day,  the  beginrung  of  Operation  Desert  Shield.'  Between 
then  and  mid-November,  Air  Force,  Army,  Marine,  and  Navy  units  moved  uito 
the  theater  to  protect  Saudi  Arabian  and  U.S.  interests  from  Iraqi  attack. 


On  November  S,  President  Bush  announced  the  initiation  of  a  new  phase  of 
deployments  to  Saudi  Arabia.  The  subsequent  movement  of  two  and  one-third 
armored  divisions,  an  armored  cavalry  regiment,  a  combat  aviation  brigade,  and 
selected  elements  of  the  VII  Corps  command  and  support  structure  from  Europe 
and  the  1st  Infantry  Division  (Mechanized)  from  Fort  Riley,  Kansas,  substantially 
increased  U.S.  capabiUties  in  Saudi  Arabia  and  allowed  offensive  operations  to 
begin. 


'  U.S.  Department  of  Defense,  Conduct  of  the  Persian  Culf  Final  Report  to  Congress,  Pursuant 
io  Title  V  of  the  Per$ian  Gulf  Ccnfhcl  Supplemental  Auihonzatwn  and  Personnel  Benefits  Act  of  1991  (Public 
Lav/  102-23),  Washington,  D.C.:  U.3  Government  Pnntmg  Office.  April  1992,  p.  44. 
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Figure  10 — ODS  Timeline 

D-day  marked  the  initiation  ot  the  air  war  on  January  17,  1991,  and  G-day  marked  the 
start  of  the  ground  war  on  February  24.  Then  at  8:00  A.M.  local  time  on  February'  28, 
offensive  operations  ended  and  both  wars  were  essentially  over.  By  March  9,  SITREPS 
had  reverted  to  designating  time  in  C-days. 

Prior  to  the  Crisis 

USCENTCOM  had,  in  previous  years,  used  the  deliberate-planning  process  to 
generate  a  number  of  OPLANS  for  Middle  Eastern  scenarios,  none  of  w’hich 
corresponded  veiy-  closely  (o  the  ODS  situahon.  Fortunately,  USCENTCOM  had 
more  recently  conducted  a  major  review  of  its  primary  OPLAN  and  decided  to 
refocus  on  an  exigency  very  similar  t>-  vhat  was  about  to  happen.  This  new  plan, 
however,  was  still  in  the  early  stages  of  development.^  USCENTCOM  had  also 
recently  sponsored  a  Conunand  Post  Exercise  ("Internal  Look")  exercising 
portions  of  the  new  plan — although  it  appears  that  this  was  almost  exclusively  a 
wargaming  of  the  employment  options,  beginning  about  C+30.  Finally,  the  XVIll 
Corps  had  recently  submitted  its  portion  of  the  movement  requirements  file  of 
the  new  USCENTCOM  plan  to  Forces  Command  for  sourcing.  These  documents 
and  databases  existed  at  the  end  of  Julv  1990,  before  the  Iraqi  invasion  of  Kuwait. 
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^Thc  IX'D  reporli  that  USCENTCOM  drah  Operations  Plan  (OPLAN)  1002 -90,  Defense  of  the 
Arabian  Peninsula,  ’.vas  undergoing  final  review  m  August  1990.  Subsequent  paragraphs,  however, 
suggest  that  the  concept  of  operations  may  have  been  set  and  the  force  requirements  lest  partially 
completed,  but  that  "TPFDD  conferences,  which  involve  representatives  from  all  service  elements, 
were  scheduled  for  November  1990  and  February  1991.  A  final  deployment  plan  was  due  to  be 
published  in  Apnl  1991  and  supporting  plans  in  .August  1991.  " 
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Deploying  Forces — August  Through  October 

On  August  2,  Iraqi  troops  attacked  and  overran  Kuwait.  U.S.  intelligence  sources 
had  been  following  the  buildup  of  Iraqi  troops  for  some  time  but  had  not  been 
convuiced  Iraq  would  attack  unhl  )ust  a  tew  days  before  it  happened.  The 
subsequent  massmg  of  Iraqi  troops  to  the  south,  along  the  border  with  Saudi 
Arabia,  caused  further  concern  both  for  the  integrity  of  existing  Middle  Eastern 
nations  and  for  the  safeh'  of  major  oil  fields.  Seeing  the  need  to  react  quickly, 

U.S.  authorities  consulted  with  Saudi  Arabia  and  quickly  called  for  the 
deployment  of  U.S.  troops. 

Consequently,  cnsis-action  procedures  were  mvoked  with  the  knowledge  that 
Iraqi  troops  had  overtaken  one  nation  and  were  poised  to  attack  a  second. 
Everyone  felt  that  speed  was  vital.  Major  uncertainties  abounded  over  what 
Saddam  Hussein's  intentions  might  be,  what  other  nahons  in  the  region  and 
around  the  world  were  thinking  and  how  they  might  react  to  U.S.  slaieinents  and 
actions,  what  courses  of  action  the  United  States  should  take,  what  risks  each 
course  posed,  and  what  alternative  force  lists  might  best  be  deployed. 

This  was  not  a  completely  "no-plan"  situahon,  as  the  beginnings  of  the  specific 
plan  were  available  and  parts  of  several  older  plans  also  were  relevant.  However 
mudi  those  may  have  helped,  though,  there  w’as  much  less  of  a  plan  than  most 
deployment  officials  were  accustomed  to  dealing  with  in  exercises  or  even  in 
theory. 

Initial  Planning 

The  Joint  Staff  initiated  the  cnsis-achon  planning  for  Operation  Desert  Shield. 

The  beginning  was  chaotic:  During  the  first  96  hours,  USCINCCENT  conducted 
close-hold  planning.  Decisions  were  made  at  the  General  officer  level,  mostly 
over  telephones  with  hard  copy  (sometimes)  following.  Many  of  the  major 
decisions  were  made  before  relevant  data  were  (or  could  be)  put  into  the 
databases. 

Much  of  the  initial  planning  took  place  at  MacDill  Air  Force  Base,  home  of 
USCENTCOM,  and  at  Fort  McPherson,  home  of  FORSCOM.  FORSCOM  and 
ARGENT  (Army  component,  U.S.  Central  Command)  were  the  major  /'^rmy- 
specific  players  in  early  ODS  pleinning.  In  the  previous  section  of  this  report  we 
described  some  of  the  complexity  of  the  decisions  and  the  organizational 
interactions  that  are  required  to  select,  ready,  and  deploy  forces.  Those  could  all 
work  efficiently  and  effectively  together — i/the  plans  were  all  perfect  (or  nearly 
so)  and  if  nothing  ever  changed  to  affect  anv  of  those  plans.  In  ODS,  however. 
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many  things  were  going  on  simultaneously  and  changes  were  constantly  being 
made  to  all  aspects  of  the  plan. 

Still,  it  can  be  argued  that  die  United  States  chose  an  appropriate  balance  m  ODS 
Lcb.vccn  rcsporisivonocs  a^ad  building  the  combat  pov/cr  ncccssar  in-theater  to 
transfonn  a  "short  warning"  sccnano  to  a  long  wammg  one.  The  decision  to 
build  a  significant  presence  m  a  (relatively)  secure  position,  coupled  with  those 
military  actions  necessary'  to  protect  th"*!  buildup,  allowed  tune  to  establish  a 
worldwide  coalition  and  move  a  capable  force  uito  the  theater. 

The  United  States  accomplished  this  by  moving  forces  in  the  follow uig  sequence: 

•  Air  Force  tactical  aviation  and  strategic  bombers  provided  a  quick-response 
conventional  deterrence  capabUity. 

•  The  Army  airborne  and  au  assault  forces  provided  a  quick-reaction  security 
presence. 

•  Naval  aviation  augmented  the  conventional  deterrence  capability. 

‘  Marine  forces  augmented  this  security  presence  and  began  to  build  a 
defensive  capability'  in-theater. 

•  Naval  forces  provided  security  for  shipping  and  ports  to  enable  further 
remforcement. 

•  Army  armored  combat  power  reinforced  the  theater's  defensive  combat 
capability  and  began  to  build  a  counteroffensive  capability. 

ChcKising  the  nght  strategic  alternative  resulted  in  a  markedly  different  military- 
role  than  onginally  envisioned;  a  successful  deterrence  phase  resulted  ui  a 
coimteroffensive  phase.  We  now  look  more  closely  at  the  Army's  portion  of  this. 

Specifying  Forces  for  the  Initial  Deployments 

As  noted  earlier,  this  was  not  a  completely  no-plan  situation  and  top-level 
planners  at  the  White  House,  the  Pentagon,  and  USCENTCOM  quickly  produced 
a  fairly  complete  specification  of  the  initial  combat  units  to  be  sent  to  Saud- 
Arabia  and  informed  the  transportation  community  of  their  immediate  needs 
and  also  of  the  magnitude  of  possible  follow-on  requirements. 

Ttiose  actions  allowed  the  combat  forces  to  begin  deploymg  almost  immediately. 
Tfie  first  division-ready  brigade  of  the  82nd  Airborne  Division  began  to  move  on 
August  8;  the  first  division-ready  brigade  of  the  24th  Infantry  Division 
(Mecharuzed)  began  to  move  on  August  9;  and  lead  elements  of  the  101st 
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lufantrv'  Division  began  to  move  on  August  11.  Communications  among  the  top- 
level  commands  about  the  scope  of  ODS  combat  unit  deplovmcnts  appear  to 
have  been  prompt  and  appropriate.-^ 

llie  rapid-depioymeni  units  of  <>ii  tiie  Services  are  practiced  in  responding 
quickly  to  rapidly  e'  olving  crises.  Doctrine  requires  them  and  their 
accompanying  equipment  and  supplies  to  be  inventoried  and  ready  for 
immediate  loading.  Consequently,  *heir  transportation  requirements  can  be 
quicklv  calculated,  and  since  tl  ^se  forces  are  relatively  small  and  their  priorities 
are  relatively  high,  thev  can  be  quickly  deploved. 

Even  as  those  initial  '.and  essentially  preprogrammed)  forces  were  being  set  in 
motion,  however,  serious  planning  tor  the  remau-.der  of  the  initial  deployments 
was  under  way. 


Moving  the  Combat  Forces 

Du.  mg  the  ntsl  '.veek  of  ODS,  the  CJCS  allocated  the  entire  AMC  fleet  to 
USCENTCOM.  Normal  prcKedure  is  for  the  CINC  to  attempt  to  allocate  the 
available  lift  among  the  services  in  a  somewhat  stable  manner,  but 
USCENTCOM  quickly  found  that  events  were  changing  too  fast  for  Uiat  to  work. 
They  then  set  up  a  daily  priority  listing  and  coordinated  that  with 
USTR,'\.NSCOM.  A  problem  for  the  analysts  was  to  translate  numbers  of  aircraft 
uUi.)  numbers  of  passengers  and  tonnages  of  cargoes  that  they  could  carry  over 
long  distances,  with  the  constraint  that  they  were  just  leammg  which  countries 
they  could  overfly,  land  in,  refuel  in,  etc.  They  also  had  the  initial  constraint  of 
having  clearance  to  disembark  at  only  a  single  airfield  in  Saudi  Arabia. 

In  a  fully  planned  I'peianon,  a  pre-prepared  TI’FDD  would  identify  units  and 
their  deployment  dales.  In  the  initial  stages  of  ODS  that  information  was  passed 
in  message  traffic.  The  TTFDD  would  also  contam  estimates  of  the  equipment  in 
i-ach  unit  and  its  weight  and  volume.  Transport  planners  could  then  translate 
that  infonnation  into  appropriate  airlift  and  sealift  plans.  ODS,  however,  was 
not  a  fully  planned  contingency.  During  most  of  August,  people  at  the  different 
organizations  were  all  entering  information  into  the  depiloyment  databases.  The 
l'C3KSCOM  VVWMCCS  system  was  often  overloaded,  causing  extended  delays.  It 


^1  Siring;  I  hr  nrxl  JdV',,  Itir  ri-Miiiinin(’,  hni;,!.!!-.  i>l  thr  Z'lth.  H2ihI,  Ihr  1x1,  and  thi-  101  sI  wire 
di'plnvixt,  dlony;  wilh  Ihe  1x1  Cavain  IJivixinn,  llir  Ird  Amiorcd  l  avalry  Kc^imrnl,  Ihc  l')7th 
Separair  Infanirv  Brigade,  Ihc  1 ,1  Brigade  ol  Ihc  2nd  Aminriti  Uivixion,  thr  12lh  and  the  l  .Hth 
.■Vvialinn  Bngadex,  and  ma|(ir  elemcnix  ol  AKC  l.K  I  ith.-  'rd  Amiv),  XVIII  C  iirj>x  and  Ihc  1x1  I  iirpx 
Support  (.omniand  K  C2SCOM) 


was  not  until  late  in  the  month  that  the  databases  contained  sufficient 
informahon  to  be  useful  in  actually  moving  the  troops  and  equipment.'* 

During  this  period,  and  in  fact  during  the  entire  operation,  W'W'MCCS 
teleconferencing  provided  the  main  means  of  communications  for  both  planning 
and  execution.  Established  by  IISTRANSCOM  in  early  .August,  a  command 
teleconference  served  the  CINCs,  a  more  general  teleconference  interconnected 
all  elements  of  the  deployment  community,  and  specialized  USTRANSCOM  and 
MTMC  teleconferences  served  the  major  transporters. 


Specifying  the  Support  Forces 

The  process  for  non-du  isional  Army  combat  seivice  support  (CSS)  was 
somewhat  different.  USCEMTCOM's  concept  of  logistics  support  provided  that 
the  "Ser\’ices  will  provide  logistics  support,"  though  USCENTCOM  w'ould 
exercise  "overall  directive  authority"  for  logishcs.  FORSCOM  thus  prov.d.'d 
most  of  the  guidance  and  orders  for  Army  logistics  and  other  CS  and  CSS 
capabilities.  On  August  10,  FORSCOM  issued  a  deployment  order  identifying 
scores  of  non-divisional  units.  The  message  identified  the  units  and  defined 
available  to  load  dates  (ALDs),  earliest  arrival  dates  (EADs),  and  latest  arrival 
dates  (LADs)  for  each.  Copies  of  this  message  went  to  USTRANSCOM,  MSC,  the 
Mantime  Administrahon  (MAJIAD),  MTMC,  and  AlvlC.  That  started  the 
deplovTnent  of  support  unils.  Then  ovt.  the  next  two  weeks  FORSCOM  issued 
at  least  nine  messages  to  the  same  distnbution  providing  correchons  and 
additions  to  its  irutial  list.  The  impression  is  one  of  full  exchanges  of  information 
on  the  identification  of  deploying  units  between  the  Army  and  the  transportation 
community,  but  also  of  major  uncertainty  and  variability. 

The  establishment  of  the  CSS  force  structure  was  an  iterative  process  mvolvmg 
three  major  players;  The  Office  of  tlie  Deputy  Chief  of  Staff  of  the  Army  for 
Logistics  (DCSLOG)  recommended  CSS  structure  to  FORSCOM.  FORSCOM 
scrubbed  the  list  for  feasibility'  and  desirability  and  forwarded  its 
recommendation  to  USCENTCOM.  USCENTCOM  made  mmor  changes  and 
then  returned  the  list  to  FORSCOM  as  the  "CINC's  requirements." 

Once  a  requirement  was  established  it  became  FORSCOM's  responsibility  to 
source  it  if  it  was  a  imit  requirement,  or  the  responsibility'  of  the  Traimng  and 
Doctrine  Command  (TRADOC)  to  source  it  if  it  w'as  an  mdividual/skill 


■^To  tr\’  to  alleviate  seme  of  the  overload.  Honev'vvell  quicklv  made  available,  through  ■■SWIS, 
two  unused  DPS-8  computers  that  were  installed  at  FORSCOM  in  early  September. 
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requiromcnt.  That  is,  FORSCOM  would  select  truck  companies,  but  TR.ADOC 
would  identify  additional  drivers  if  they  were  needed. 

r.  urging  is  genet.dly  not  as  simple  as  it  sounds.  Not  only  is  it  difficult  ti'  cliooso 
among  similar  units,  but  it  is  difficult  to  determme  which  imit  is  "more  ready" 

(or  can  become  ready  by  a  particular  date).  In  general,  FORSCOM  (and  the 
Army  staff)  consult  tlie  readmess  database  (SORTS)  to  determine  the  status  of 
units  and  how  much  training  and  equippmg  they  wouid  need  before  they  could 
be  deployed.  Tlien  they  use  tlie  MSPS  database  to  ass‘.*ss  and  schedule  the  flov\' 
of  units  through  mobilization  centers. 

For  Army  units  in  CONUS,  FORSCOM  sources  the  "imit,"  but  in  almost  every 
case  that  unit  then  has  to  decide  (based  on  guidance  from  the  CINC,  FC)HSCOM, 
and  others)  which  subsidiary  units  it  needs  to  take  along.  That  is,  it  needs  to  be 
tailored,  or  to  tailor  itself,  for  the  job  that  the  CINC  has  described. 

Units  can  task  only  those  subunits  withm  their  command,  if  an  .Army  unit  wants 
support  from  another  unit,  it  must  make  a  request  tJirough  FORSCOM.  For 
example,  if  tlie  7th  Infantry  Divtsion  needs  a  non-divisional  truck  company,  it 
must  request  the  company  through  FORSCOM  ^ 

In  ODS,  USCENTCOM's  needs  and  policies  evolved  over  time.  Earl)’  m  tlie 
deployment  it  maximized  the  flow  of  combat  units,  deploymg  only  enough 
support  troops  to  manage  the  front  end  of  the  deployments  and  stagings.  Then 
during  the  October/ November  time  frame  the  policy  evolved  mto  developmg  a 
strong  offensive  capability,  which  required  a  full  CSS  structure.  In  early  October, 
a  table  of  organization  and  equipment  for  a  theater  anny  area  command  (a 
TAACOM)  was  faxed  to  die  commanding  general  of  ARCENT,  initiatmg  the 
establishment  of  personnel  billets.  Soon  after,  the  augmentation  package 
designed  for  the  21st  TAACOM  of  US/\REUR  was  sent  to  Saudi  Arabia, 
providmg  tlie  ARCENT  Support  Command  (Provisional)  with  an  additional 
general  officer  and  several  hundred  augmentees.  In  December,  the  .ARCENT 
SupCom  (Provisional)  officially  became  the  22nd  Support  Command  with  direct 
responsibility'  to  USCENTCOM. 


■^In  tact,  somptimes  F'ORSCOM  dofs  more  than  lu.'it  support  the  CINC's  plan  Honduras  is  .in 
example  of  how  FORSCOM  can  wear  the  hats  of  supportt.*d  and  supfxirtin^  coinmand  at  the  same 
time  In  that  of'eration,  the  L'.S.  Southern  Command  did  not  fivl  comforMhle  usink;  st' 

F(')RSC'C^M  (1 )  built  the  plan,  (2)  developed  the  rcH^uirements.  (3)  sourci'-d  the  rt'mnrenient.s,  and  t4) 
^ave  the  units  goals  of  w  fiat  to  take  and  not  to  take. 


Estimatmg  Transport  Rcijuircmcnts  for  the  Support  Forces 


LXiruig  th;j  period  FOr^GCOM  was  perfom\mg  JO^’ES  activ  ities  tor  most  oi  the 
CONTL'S  Army  units.  FOl^COM  recewed  deployment  detail  from  units  hy  e- 
mail,  telephone,  and  special  messenger  and  entered  tlie  data  into  JOPES  for  the 
units.  This  was  done  for  several  reasons;  some  units  did  not  have  VVVVMCCS 
terminals  available  to  do  it  themselves,  and  others  were  not  expert  with  the 
equipment  they  did  have.  Finally,  it  allowed  FORSCOM  to  act  as  at  least  an 
informal  reviewer  of  data  before  thev  were  entered. 


•As  a  general  rule,  FORSCOM  tried  not  to  enter  data  into  the  deplovment 
database  until  there  was  a  high  degree  of  confidence  tliat  thev  were  correct  and 
appropriate.  This  was  accomplished  b}'  ‘’xarrunmg  and  coordinating  the  Cl\’C's 
priorities  with  the  component  command's  deployment  data  and 
L'STRANSCOM's  resources  md  plans.  Even  so,  the  data  often  imderwent  later 
changes. 


For  example,  FORSCOM  tried  not  to  enter  infomiation  concemmg  available  to 
load  dates  (for  particular  urdts)  into  JOPES  until  those  dates  were  coordinated 
botii  vvitii  tite  units  and  witi'  IdSTRATvJSCOM.  If  the  units  could  not  be  moved 


Within  a  reasonable  tune  after  their  ALDs,  theie  was  no  reason  to  have  them  rush 
to  bo  ready  then  or  to  wait  at  tlic  ports.  Thus,  the  deployment  database  often 
really  represented  the  end  of  detailed  negotiations  which  occurred  by  phone,  fax, 
or  e-mail. 


During  ODS  (as  during  other  recent  operations),  there  were  really  tliree  major 
channels  for  sharmg  deployment  information.  In  adadion  to  the  official  JOPES 
deployment  databases  and  the  WIN  teleconferences,  much  use  was  made  of 
more  direct  forms  of  communication,  such  as  the  telephone  and  fax.  Typically, 
the  mo,'e  important  mformation  was  communicated  from  Chief  of  Staff  to  Chief 
of  Staff,  or  from  Deputy  Chief  of  Staff  for  Operations  (DCSOP)  to  DC50P,  then 
FORSCOM  was  told  what  units  were  to  go.  Most  teleconfercncmg,  however, 
took  place  at  the  action  officer-to-action  officer  level  rather  than  higher  up. 


Moving  the  Support  Forces 

FOI^COM  IS  officially  responsible  for  planning  Uie  move  of  support  forces  and 
for  continually  updating  the  database  as  CONUS  .Aimv  units  move  from  their 
posts  through  to  their  destinations.  If  tlie  unit  is  not  deployed  as  plaimed,  it  ls 
FORSCOM's  responsibility  to  rephase  it  and  to  update  the  deplovment  database 
FORSCOM  had  been  validatmg  mo\  ement  requirements  and  recordmg 
movements  during  exercises  for  years,  but  tho.se  had  been  essentially  emptv 
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tasks.  In  ODS,  however,  it  quickly  became  obvious  that  those  tasks  were  not 
appropriate  for  FORSCOM,  and  soon  they  were  turned  over  to  AMC.  VVe 
discuss  this  more  in  Sechon  5. 

Technical  Assistance  from  USTRANSCOM 

USTRANSCOM  has,  for  several  years,  been  re.sponsible  for  crisis-acbon  planning 
(the  JDS  part  of  JOPES).  It  conducts  all  the  JOPES  crisis-action  training,  and  its 
personnel  are  well-known  throughout  the  community.  So  it  was  natural  that 
USTRANSCOM  sent  technical  assistance  teams  to  USCENTCOM  (at  MacDilJ) 
aiad  FORSCOM  early  in  ODS  to  help  with  deployment  planning  and  database 
construction. 

By  August  10  when  the  USTICANSCOM  team  arrived,  USCENTCOM  and  its 
components  (ARGENT,  CENTAF,  MAJiCENT,  and  NAVCENT)  had  put  together 
a  general  plan  with  some  degree  of  notional  units  and  phasing.  It  named  some 
specific  combat  forces  but  was  still  mostly  a  wish  list. 

During  the  first  few  days,  no  one  really  knew  which  units  were  needed  or,  except 
for  a  few  like  the  82nd,  the  101st,  and  the  Marines,  which  ones  were  reaby 
available.  So  there  was  little  real  data,  let  alone  time,  to  get  them  into  the 
database.  The  CINC's  "priority  list,"  a  miru-database  that  could  be  handled  (and 
retyped  several  times  a  day)  manually,  provided  the  initial  coordinations. 

The  problem  during  the  first  vs  eek  of  the  crisis  was  not  that  units  could  not  be 
moved,  but  that  the  CINC's  planning  could  not  be  supported  as  it  needed  to  be. 
The  advantage  of  having  (or  of  having  access  to)  a  commoi,  database  is  that  it 
collects  and  shows  the  aggregate  as  well  as  individual  resource  movements  and 
needs.  If  problems  aruse,  or  even  more  important,  if  the  CEsJC  needs  to  rethink 
any  of  his  options,  the  analysts  can  quickly  tell  him  the  impbcations  of  those 
changes,  in  terms  of  wliat  other  unit  movements  must  be  slowed,  abandoned,  cic. 

By  the  end  of  August  USCENTCOM  had  the  first  really  useful  database 
describing  how  big  the  operation  was  and  how  the  units  were  expected  to  phase 
into  the  theater,  as  well  as  indicating  how  much  transportation  would  Lc  needed 
and  what  had  already  been  moved.  Tliat  database  had  been  built  in  15  to  20 
days,  despite  the  uncertainties  and  despite  the  inefficiencies  of  JOPES  and  the 
lack  of  integration  of  the  JOP5  and  JDS  subsystems.  This  spoke  well  for  the 
ability  and  dedication  of  tlie  USCENTCOM  and  USTICANSCOM  teams. 
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Deploying  Forces — November  Through  January 

On  November  8,  President  Bush  announced  a  new  phase  of  deployments  to 
Saudi  .Arabia.  The  movement  of  two  and  one-third  armored  divisions,  an 
armored  cavalrv'  regiment  (ACR),  a  combat  aviation  brigade,  and  selected 
elemer.ts  of  the  VII  Corps  command  and  support  structure  from  Europe  and  the 
1st  Infantry  Division  (Mechanized)  from  Fort  Riley,  Kansas,  substantially 
increased  U.S.  offensive  capabilities  in  Saudi  Arabia.  These  deployments  also 
provided  further  chaUenges  for  the  U.S.  deployment  community. 

Planning  for  these  movements  differed  greatly  from  that  for  the  earlier 
movements.  Here,  there  v/as  time  to  estimate  the  transportahon  feasibility  of  the 
moves  and  to  build  die  deployment  databases  before  the  majority  of  tlie  cargoes 
started  to  move. 

One  story  heard  from  several  sources  concerns  tlie  transportation  estimates. 
USTRANSCO.M  was  asked  about  die  feasibility  of  moving  the  two  heavy 
divisions  plus  the  ACR  plus  the  support  elements  from  Germany  to  Saudi  Arabia 
by  January  15, 1991.  USTRANSCOM  made  its  estimates  and  replied  that,  yes,  it 
could  be  done  if  certain  amounts  of  airlift  and  sealift  were  dedicated  to  that  task. 
So  Lhe  move  was  called  "transportahonally  feasible." 

However,  USTRANSCOM  had  assumed  an  immediate  start  for  the  deployments, 
while  in  reality  the  deployments  were  not  announced  by  the  President  and  the 
movements  were  not  allowed  to  begin  until  several  weeks  later.  This  resulted,  as 
we  all  know,  in  many  of  the  cargoes  arriving  several  weeks  after  January  15. 

The  moral  of  the  stor\'  Ls  that  even  if  the  treinsportation  community  does  have 
time  to  estimate  its  current  capacity  and  its  capability  for  moving  specified 
forces,  those  plans  are  only  as  good  as  their  weakest  assumption.  Just  because  i 
set  of  movements  is  hansportationally  feasible  under  one  set  of  assumptions  it  is 
not  necessarily  feasible  under  anollier  set,  or  in  the  real  world  of  constant  change. 

Improved  Cargo  Lists 

By  November  some  Army  units  could  generate  detailed  deployment  cargo  data 
and  electronically  forward  those  to  FORSCOM  and  the  transportation 
organizations.  For  example;  At  Fort  Riley  the  installation  transportation  office 
had  TC-.ACCI5  records  on  the  equipment  and  supplies  owned  by  the  1st  Infantry 
Division  (Mechanized).  When  it  learned  whicli  companies  were  to  be  deployed  it 
called  in  their  5-4  representatives  and  updated  the  holdmgs  information  as  much 
as  possible.  Then  it  transmitted  those  unit  equipment  lists  (UELs)  to  FORSCO.M 
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and  to  N-fTMC.  At  FORSCOM  thie  information  was  entered  into  COMPASS, 
where  transactions  were  generated  to  put  it  into  the  Unit  Movement  Data  (UMD) 
subfile  of  JOPES. 

The  TC-.'XCCIS  systems  at  the  installatiorv?  also  generated  bar-code  labels  for 
each  piece  of  equipment  identified  in  the  automated  unit  equipment  lists 
(.■\UELs).  It  is  the  formatted  AUEL  information  that  is  forwarded  to  MTMC.  The 
Logistics  Marking  and  Reading  Symbols  system  (LOGMARS)  creates,  produces, 
and  reads  the  “bar  coded"  labels  tliat  are  stuck  on  all  types  of  military'  items.  The 
transportahon-related  labels  referred  to  here  contain  the  Transportation  Control 
Number  for  the  particular  piece  of  cargo  (this  includes  a  code  idenhfymg  the 
owner  of  the  cargo),  a  bumper  number,  model  number,  dimensions  (length, 
width,  height),  weight  in  po'unds,  cube  in  feet,  measurement  tons  (this  is  a 
notional  factor  equal  to  40  cubic  feet  of  typical  military  equipment),  commodity 
number,  U'pe  pack,  and  an  item  description  (e.g.,  1TRA.ILER  ACFT  MAINT, 
IHELICOPTER  LTILITY,  IBOX  SHIP  METAL  20  FT,  etc.).  MTMC  uses  this 
information  to  alert  the  ports  as  to  uhat  is  coming,  to  open  (or  size)  contracts 
with  the  railroads,  and  to  call  for  ships.  It  passes  the  mfo.mation  to  its  uruts 
workmg  the  ports. 

For  example,  the  1191st  Terminal  Transportation  Unit  worked  the  port  at 
Houston  that  processed  the  1st  ID's  equipment.  Members  of  the  unit  received 
the  cargo  Usting  from  MTMC  telling  them  what  to  expect.  WTien  the  trains 
arnvoa,  they  scanned  the  LOGMARS  labels  as  each  piece  of  equipment  was 
offloaded  and  moved  to  tlie  storage  area.  Then  they  scanned  the  labels  agam 
after  each  piece  was  stowed  aboard  ship,  noting  its  stowage  location.  This  last 
process  produced  the  "ship's  manifest."  It  was  MTMC's  task  to  be  sure  that 
manifest  data  was  then  entered  mto  the  JOPES  deployment  database.^ 

Deployments  from  Europe 

On  November  8,  the  secrecy  blanket  was  lifted  on  planning  for  the  movement  of 
troops  and  equipment  from  Europe.  By  Sunday,  November  11,  USEUCOM  had 
received  liaison  officers  from  USCINCCEN"!,  USCLNCCENT  (rear),  and  from 
USTRANSCOM.  USTRANSCOM  m  fact  dispatched  a  number  of  support  teams 
to  the  theater,  including  three  to  USEUCOM;  one  to  help  prepare  tlie  TPFDD; 


LUiitrast  the  piece-U-vel  intofTnation  in  the  manifests,  however,  the  entries  were 

only  at  ihe  unit  lin#>  number  (ULN»  level 
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one  to  assist  with  use  of  the  DART  system;’  and  one  to  supervise  JOPES  inputs. 
USTRANSCOM  also  dispatched  a  three  member  team  of  JOPES  experts  to 
USAREUR. 

>1005  teleconferencing  provided  the  mam  means  of  communications  durmg 
both  planning  and  execution  in  Europe.  Within  the  theater  a  teleconference 
named  TRANScUR  that  had  been  set  up  in  Februarv'  was  being  used  intensively 
for  local  messages.  The  major  ODS  teleconferences,  established  by 
USTRANSCOM  back  m  August,  were  also  available  to  qualified  commands:  The 
coi  .nand  teleconference  was  used  by  the  CINCS,  and  the  USTRANSCOM  and 
MTMC  teleconferences  were  used  by  those  organbahon*^.  .’.nd  monitored  by 
almost  everj'one  else. 

USAREUR  submitted  its  first  troop  list  and  draft  OPORD  to  USEUCOM  on 
November  10.  On  November  11,  it  received  its  deployment  order. 

The  deployment  database  for  the  movements  from  Europe  was  prepared  in 
about  10  days.  The  joint  systems  planner  at  HQ  USEUCOM  took  charge  of  the 
structure  of  the  TPFDD,  the  planners  at  USAREUR  created  the  force  composition 
and  flow  for  the  Army  units,  and  USCINCCENT  set  tlie  EADs  and  LADs. 

The  first  version  of  the  deployment  database  was  based  on  notional  units  and 
data  from  the  JOPES  Type  Units  Characteristics  (TUCHA)  file,  as  the  equipment 
mventory  mformation  for  some  of  the  units  was  out  of  date.  Then,  as  TC-ACCIS 
w'as  imported  frem  COhTJS  and  more  up-to-date  information  became  available, 
they  converted  the  notional  plan  to  an  actual  plan.  Throughout  this  period 
USAREUR  insisted  on  working  with  Level  4  data  even  though  USCENTCOM 
mdicated  it  would  have  preferred  a  (faster)  initial  tumaroimd  with  Level  2  data. 

MTMC  Europe  also  expressed  concern  for  the  TUCHA  data  and  for  the  delays  in 
waitmg  for  the  TC-.ACCIS  information.  It  based  its  mitial  estimates  of  caigo 
requirements  for  sealift  on  different  data  and  claimed  better  accuracy.  It 
accessed  the  Requisition  Validation  files  for  the  moving  units,  clainimg  those  files 
were  more  representative  of  what  the  units  actually  had  on  hand.  That  inav  have 
been  true,  but  soon  thereafter  the  TC-ACCIS  data  became  available  and 
improved  all  of  the  estimates. 


y 

DART,  till’  lAnamit  Anaiylit.il  Ki'plannmg  I  out,  had  lusl  been  a.ssombk-d  Inmi  nffthv-shi'lf 
harduarr  and  software  by  the  Advanci'd  Kest-arrh  Pro|ccl,s  Agrnev  ;AKPA)  and  Rome  Air 
r)i*vi*lopmi*nt  Center  to  demitnstrate  to  US  TTCAN'SCOM  the  benefits  of  current  cotxipuler  trH.'hnoIogv 
for  deployment  planning  Diinng  ODS  it  proved  useful  to  both  t  Sn<A\'SCOM  and  USIiUCOM  in 
tracfung  the  number  of  ships  required  for  tne  second-phase  depi  yment.s  and  as  a  tiandy  means  for 
making  daily  backups  of  portions  of  the  deployment  databas4-. 
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All  of  file  organizations  we  interviewed  in  Europe — USEUCOM,  L'SAREUR,  and 
NfTMC-EUR — operated  with  Version  3  of  JOPES,  which  had  been  installed  only  a 
few  weeks  previously.  They  all  expressed  some  concern  that  the  changeover 
from  Version  2  had  taken  place  right  in  the  middle  of  ODS  operations,  causing 
their  systems  to  be  down  for  the  better  part  of  a  day  when  they  could  least  afford 
the  delay. 

Differences  Between  Initial  and  Subsequent  Deployments 

There  were  a  number  of  important  differences  between  the  organizations 
deploying  in  Phase  I  .and  Phase  II.  For  example,  USAREUR  had  a  relatively  large 
number  of  people  who  were  experienced  with,  JOPES  and  USEUCOM  had  a  good 
base  ot  information  to  start  with  in  their  pnmar\'  OPLAN.**  This  made  it  easier 
for  them  to  identify  units  and  gave  their  planners  more  time  to  think  about  how 
to  move  things.  In  addihon,  the  situahon  in  the  Gulf  was  more  stable  at  this  time 
so  the  plarming  mformahon  was  Ics.  jubject  to  diaiige.  Ii'  spite  of  all  the  le.sjons 
learned  up  to  that  pomt,  however,  the  timeliness  and  accuracy  of  cargo  data  was 
a  contmumg  problem. 

U5TRA.NSCOM  reports  that  one  of  the  major  successes  of  the  Phase  ii 
deployTTients  was  the  use  of  TC-ACCIS  data,  especially  in  Europe. 
USTRANSCOM  contends  its  components  need  Level  4  detail  or  better,  so 
USAREUR  had  to  task  all  of  the  deploying  units'  S-4s  to  count  and  measure  their 
vehicles  and  equipment.  Each  unit  had  many  nonstandard  items  and  modified 
equipment.  This  mformahon  was  all  entered  into  TC-ACCIS;  then  it  was  all  re¬ 
entered  manually  mto  JOPES  (this  alone  took  five  days),  since  there  w-as  no  link 
between  the  two  systems  except  at  FORSCOM. 

USTRANSCOM  personnel  contend  that  for  execution  JOPES  needs  bottom-up 
force  information.  They  believe  that  if  IC-ACCIS  could  directly  update  JOPES  or 
their  Global  Transportation  Network  it  would  make  execution  much  easier. 
FORSCOM,  on  the  other  hand,  believes  the  updating  should  only  be  through 
command  channels.  They  say  that  if  tlie  UEL  update  process  begins  to  work  as 
intended  and  the  AWIS  transportation  product  Ime  provides  for  more  rapid 
updating  of  JOPES,  then  most  of  the  shortfalls  would  be  satisfied. 

The  USTIUANSCOM  team  refiorted,  however,  that  oven  with  the  help  of 
TC-ACCIS  the  early  estimates  of  cargo  movements  from  Europe  were  still  about 


^On  the  otfu'r  hand,  [-uropi'an  based  units  Iiad  not  expt.'cted  to  deplov  to  anoth.’r  region  and 
had  ftfVer  trained  to  deploy 
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1  million  square  feet  off  from  what  was  actually  moved.  This  is  an  error  o' 
between  5  and  10  percent.  No  one  has  a  good  idea  of  how  far  off  the  estunates 
were  for  the  Phase  I  deployments,  however,  so  the  two  cannot  be  compared. 


Summary 

Participants  who  planned  and  conducted  the  ODS  deployments  all  report  that 
aggregate  cargo  requirements  varied  considerably  during  the  first  month  or  so. 
They  say  that  they  could  have  done  a  better  job  if  they  had  had  a  better  grasp  of 
what  was  needed;  if  the  true  magnitude  of  the  ultimate  effort  had  been  known 
from  the  outset,  decisionmaking  could  have  been  faster  and  more  precise.  For 
example,  decisions  about  activating  Ready  Reserv'e  Force  (RRF)  ships  and 
chartering  commercial  ships  might  have  been  more  timely. 

Still,  it  is  unrealistic  to  believe  that  the  "true"  magnitude  of  the  ultimate  effort 
will  ever  be  known  early  in  any  contingency.  It  is  likelv  that  the  conditions  of 
OOS — evolving  and  uncertain  requirements — will  reoccur  in  future  crises.  There 
will  always  be  uncertainty.  The  task  is  to  develop  a  command  and  control 
system  that  can  cope  with  uncertainty  and  to  train  personnel  to  take  risks  into 
account  m  preparing  for  deployments. 

This  section  described  the  major  features  of  the  planning  for  and  the  execuhon  of 
the  ODS  deployments  from  CONUS  and  Europe.  The  next  section  will  focus  on 
problems  that  arose  with  the  planning  procedures  and  systems. 
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5.  Problems  with  the  Computerized 
Support 


JOPES  and  the  other  systems  were  crucial  to  ODS.  They  allowed  establishment 
of  a  common  database  that  provided  visibility  of  the  day-by-day  progress  of  the 
deplojTnent  to  members  oi  Tie  JPEC.  If  this  capability  had  not  been  present,  or 
had  not  been  present  on  the  scale  of  JOPES/ WWMCCS,  the  ODS  deploynments 
would  have  taken  substantially  longer  and  the  frustration  level  of  the  JPEC 
would  have  been  substantially  higher.  Ne^'ertheless,  definite  problems  emerged 
during  ODS.  The  Army,  the  focus  of  this  report,  experienced  many  problems 
with  the  computerized  planning  and  monitoring  support  systems.  Even  though 
those  systems  enabled  the  large  deployment,  compared  to  commercial  standards 
the  military  support  systems  were  unfriendly,  slow,  and  prone  to  data  loss.  Four 
genercil  types  of  problems  occurred. 

•  Unfriendly,  overloaded  support  systems  resulted  in  slow  and  incorrect  data 
entries. 

•  The  design  and  control  of  the  distributed  database  resulted  in  several  losses 
of  significant  amounts  of  previously  entered  data.  This  slowed  the  creation 
of  databases  and  reports  and  reduced  their  usefulness. 

•  Procedures  for  collecting  and  entering  crucial  information  into  the  support 
systems  had  not  been  v/ell  thought  out  beforehand. 

•  The  support  systems  themselves  lacked  certain  crucial  capabilities  and 
interfaces. 

The  first  two  types  of  problems  slowed  the  computer  support,  frustrated 
personnel  involved  in  data  input  and  systems  operation,  and  may  have  delayed 
some  deployments  slightly.  The  latter  two  types  had  more  severe  repercussions, 
especially  during  the  first  several  months  of  the  deployments.  These  resulted  in 
transporters  not  knowing  what  cargoes  and  persoimel  were  supposed  to  move, 
imit  commanders  not  knowmg  the  status  and  sometimes  the  location  of  their 
resources,  and  in-theater  orgamzations  not  knowmg  what  wc’uld  arrive  on  the 
next  ship  or  plane. 

The  remainder  of  this  section  documents  examples  of  those  problems. 
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Unfriendly,  Overloaded  Systems 

There  are  never  enough  trained  operators.  USTRANSCOM  offers  a  number  of 
training  classes,  but  since  users  do  not  use  jOPES  every  day,  their  proficiency 
deteriorates  over  time.  At  the  beginning  of  ODS  there  was  a  general  lack  of 
knowledge  about  how  to  use  the  system. 

Some  of  the  training  problems  were  caused  by  condnual  staff  rotahon.  On  the 
other  hand,  purple-suit  rotation  may  have  helped  at  times  because  those  rotated 
back  into  their  ser\'ices  had  some  experience  and  traming  with  using  JOPES  for 
planning.  L'SEUCOM  and  U.S.  Atlantic  Command  (USLANTCOM)  had  well- 
trained  people  because  they  have  relatively  low  personnel  turnover. 
USCENTCOM  was  in  pretty'  good  shape  w'hen  OOS  started  but  then  forward 
deployed  some  of  its  WWMCCS  people  to  the  theater  before  the  JOPES 
workstations  arrived  in-tlieater.  The  workstations  did  not  arrive  until  30  days 
later  because,  except  for  tlie  Marine  version,  they  were  not  very  transportable. 
When  the  equipment  did  arrive,  USCENTCOM  found  that  the  through-put 
capacity  for  satellite  commumcations  between  Saudi  Arabia  and  the  United 
States  was  less  than  desired  for  fully  effective  JOPES  operations.  So  the  majority 
of  USCENTCOM’s  JOPES  tiansaclions  continued  to  be  entered  from  MacDill.^ 

Other  systems  also  were  overwhelmed.  The  European  Telephone  System  was 
particularly  overloaded  early  in  Phase  II.  So  many  demands  were  placed  on  that 
system,  the  carrier  for  most  open  as  well  as  secure  military  phone  calls  within 
Europe,  that  some  commands  found  it  to  be  virtually  unusable  between  7  A.M. 
and  8  P.M.  durmg  much  of  November,  MTMC-EUT^  adapted  by  purchasing  half 
a  million  dollars  worth  of  cellular  phones  and  reported  that  worked  weU  until 
other  organizations  moved  m  and  swamped  the  cellular  system  also. 

Very  little  error  checkmg  ls  available  within  JOPES.  In  fact,  personnel  at  both 
USTRANSCOM  and  USEUCOM,  where  DART  was  available,  suggest  that  one  of 
the  major  benefits  of  that  system  is  its  ability  to  check  for  missing  or  inconsistent 


'Mo.sI  entries  into  JOPE'-  are  made  one  line  at  a  lime,  and  most  editing  is  done  one  line  at  a  time, 
so  it  takes  a  long  time  to  enter  and  to  edit  data 

It  was  not  until  January  that  AVVIS  provided  ARCENTT  and  USCENTCOM  with  TELNET  access 
fi  om  the  theater  to  JOPES  on  the  EORSCOM  WWMCCS  node  at  Fori  McPherson.  The  A  WIS  ofhee 
had  made  no  initial  plans  to  deploy  an  Army  WWMCCS  capability  in-thealer,  smee  deployment 
planning  was  nuunly  handled  trom  CONUS Ithough,  as  noted  earlier,  USCENTCOM  deployed 
takiicg  some  of  its  WWMCCS  terminals  and  link  equipment  with  them).  However,  with  the 
possibility  of  a  longer  war  and  the  necxl  lor  troop  rolalicn,  it  became  evident  that  a  WWMCCS 
capability  in-theatcr  was  needed.  The  AWIS  Project  .Management  Office, ^Officer  (PMO)  realized  it 
might  be  texi  difficult  to  deploy  and  maintain  a  portable  mainfram"  :n  Saudi  Arabia  (which  they 
could  have  acquired  from  USEUR)  Instead  they  decided  to  provKu-  transportable  WWMCCS 
termuials  and  UT.\  communications  on  trucks  to  Riyadh  and  Dhahran  The  AWIS  commenity 
aroimd  the  world  volunteered  the  equipment. 
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data.  Errors  discovered  in  chat  manner  were  conected  in  the  DART  database 
and  then  (independently)  corrected  in  the  JOPES  database  because  of  the  fear  of 
overwriting  valid  data  (see  the  following).  Almost  everyone  agreed  that  JOPES 
needs  to  be  more  flexible  and  to  have  a  friendlier  mterface. 


Lack  of  Safeguards  for  the  Databases 

Deployment  databases  currently  can  be  accessed  by  a  number  of  people  and 
organizations,  with  little  control  over  who  can  do  what  to  each  record.  The 
following  "horror  story'"  suggests  the  types  of  things  that  happened. 

USEUCOM  personnel  report  that  early  in  their  TPFDD-building  process,  after 
consultations  w-ith  USCENTCOM,  USAREUR,  \frMC-EUR,  and 
USTRAN5COM,  they  entered  selected  dates  and  locations  into  their  version  of 
Lhe  database.  Independently,  USAREL’R  had  pulled  a  copy  of  the  database  for 
itself  and  was  identifying  units,  their  ongins,  availabilihes,  and  cargo  details  (a 
lot  of  data)  and  entering  those  into  its  %'ersion  of  the  database. 

USEUCOM  finished  its  work  first  and  sent  its  updated  version  of  the  database  to 
the  local  JOPES  computer.  Later,  having  completed  its  additions,  USAREUR  put 
its  version  into  the  same  computer,  erasing  all  the  changes  that  USEUCOM  had 
entered.  Fortunately,  the  majority  of  the  addihons  had  been  made  at  USAREUR, 
so  this  was  not  as  disastrous  as  if  tiie  cupyover  had  been  m  the  other  direction. 
On  a  smaller  scale,  anyone  who  has  write  access  to  the  system  can  rather  easily 
change  or  erase  entries  made  by  anyone  else. 

This  story  was  not  meant  to  single  out  USEUCOM,  which  in  fact  is  one  of  the 
more  experienced  organizations.  Problems  with  this  type  of  database  will 
continue  until  modem  safeguards  and  backup  systems  are  incorporated. 


Consistency  and  Timeliness  Problems  with  the  Army 
Systems 

The  Unit  Equipment  List  (UEL)  reporting  procedures  from  Army  installations  to 
COMPASS  often  result  in  a  long  delay  before  a  COMPASS  report  is  returned  to 
the  installatior  for  validation.  This  is  expected  to  improve  with  TC-ACCIS. 

Even  with  TC-ACCIS,  however,  .^UEL  data  cannot  be  directly  input  to  JOPES 
but  has  to  be  entered  through  COMPASS  to  JOPES  or  COMPASS  to  DEMSTAT 
to  JOPES.  This  allows  FORSCOM  to  review  and  validate  the  data  but  it  also 
reduces  their  timeliness  to  other  JPEC  users  such  as  U5TR,\NSCOM. 
USTRAMSCOM  has  indicated  it  vvould  like  to  receive  the  AUEL  information 
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directly  from  TC-ACCIS,  but  if  that  were  to  happen,  USTRANSCOM  would  most 
likely  have  informahon  that  was  inconsistent  with  that  in  COMPASS,  DEMSTAT, 
and  JOPES. 

DEMSTAT  collects  data  approximately  once  every  12  hours  from  sources  such  as 
JOPES,  COMP.ASS,  and  SORTS,  making  it  available  to  units  for  review  and 
updating.  However,  when  a  unit  attempts  to  correct  or  update  some  of  its 
records,  the  updates  are  not  entered  in  the  DEMSTAT  database  directly,  but 
create  transactions  into  the  source  databases.  The  units  then  have  to  wait  until 
the  next  data  coUechon  from  those  sources  updates  the  DEMSTAT  database  to 
ascertain  that  their  transactions  were  correctly  entered.  In  a  fast-moving 
deployment-planning  situatirn,  units  are  often  looking  at  data  that  arc  outdated 
and  inconsistent. 


Misunderstanding  of  Crucial  Procedures 

Some  organizations  had  problems  with  the  database,  many  had  problems  witli 
data  entry  and  checking,  and  most  suffered  from  lac.'s  of  trained  operators. 
Problems  with  requirements  vabdation  and  with  the  entry  of  scheduling  and 
manifesting  information,  however,  were  more  basic  and  more  severe. 


Verification  of  Movement  Requirements 

Prior  to  ODS,  military  planning  had  been  done  with  the  expectahon  that  units 
would  know  how  many  troops  and  how  much  cargo  they  had  to  move,  and  that 
the  transport  commands  would  be  able  to  make  solid  commitments  as  to  when 
they  would  pick  up  and  deliver  those  troops  £ind  cargoes.  But  ODS  did  not  work 
like  that.  Units  were  receiving  people,  equipment,  and  supplies  (being  "brought 
up  to  strength")  right  up  until  they  got  on  the  planes  and  trains.  Units  were  told, 
or  decided  on  their  own,  to  take  substantially  more  cargo  than  anticipated.  The 
priorities  for  transport  kept  changing.  Planes  and  ships  sometimes  broke  down. 

Many  people  expected  the  databases  to  handle  all  of  this.  /\nd  they  might 
have — if  all  changes  could  have  been  entered  immediately  (and  correctly),  and  if 
everyone  could  have  been  made  instantly  aware  of  all  the  changes  that  everyone 
else  was  entering.  But  that  was  asking  too  much. 

.A.MC  requests  five  days  of  solid  requirements  data  so  it  can  schedule  its  aircraft 
eftectively  and  efficiently.  Deploying  units  request  nearly  that  much  notification 
so  they  can  have  their  troops  ready  and  still  give  them  24  hours  of  free  tune  with 
their  families. 
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JOPE5  procedures  call  for  each  deploying  unit  to  officially  "v  alidate"  each  of  its 
movement  requirements,  that  is,  to  confirm  thut  so  many  passengers  and  so 
much  cargo  is  (or  will  be)  on  that  ramp  destined  for  that  location  on  that  dav. 

This  is  to  be  done  five  davs  before  the  move.  AMC  (for  air  cargo)  is  suppose  to 
take  the  validated  requirements  from  JOPES  five  days  in  advance,  do  its 
scheduling,  and  thien  put  the  schedule  information  back  into  JOPES  three  days 
ahead  of  time. 

OOS  provided  the  first  test  of  this  procedure,  and  several  things  quickly  became 
obvious:  few  units  could  really  validate  what  they  were  gomg  to  take;  there  were 
manv  changes;  one  urut  could  not  knowledgeably  and  effectively  ask  another 
unit  to  substitute  if  it  could  not  be  ready;  and  .AMC  could  not  schedule  and 
return  schedule  information  to  JOPES  in  two  days. 

AMC  solved  this  problem  for  the  early  CONUS  deployments  by  telephoning 
each  unit  two  days  or  so  before  the  unit  was  shown  in  the  database  as  movmg  to 
verify  for  itself  that  the  unit  would  be  ready  and  would  be  at  the  aerial  port  of 
embarkation  (APOE)  on  time.  This  phone  call  also  notified  the  unit  that  .AMC 
was,  in  fact,  sending  a  plane. 

In  theory',  the  notification  should  be  done  by  JOPES  creating  Automatic  Digital 
Network  (AUTODIN)  messages  for  transmission  to  the  unit,  but  that  could  not 
be  done  in  OE)S  because  it  often  took  six  hours  or  more  to  deliver  the  .AUTODIN 
message.  This  is  allow  able  for  port  calls  when  units  are  to  move  by  sea  because 
the  messages  can  be  issued  some  days  in  advance,  but  when  units  are  scheduled 
to  move  by  air,  and  they  and  .AMC  receive  only  48  hours  nohee  of  the  movement, 
then  AMC  has  to  telephone  them  because  AUTODIN  is  too  slow.  VVWMCCS 
messages  were  sometimes  feasible,  but  not  all  units  had  terminals. 

Entering  Movement  Information 

Information  on  incommg  cargoes  is  critical  to  the  efficient  operations  of  PODs. 
When  i.n-theater  receiving  crews  know  ahead  of  time  what  is  loaded  on  the  next 
aircraft  or  ship,  they  can  alert  the  proper  reception  and  off-loadmg  personnel, 
position  needed  handling  equipment,  arrange  for  temporarv'  storage  and/or 
staging  areas,  and,  perhaps  most  importantly,  inform  the  relevant  in-country 
units  that  they  will  have  cargo/personnel  arriving.  Without  advance 
information,  all  that  must  wait  until  the  vehicle  has  arnved  and  it.-,  contents  have 
been  examined  and  perhaps  disassembled. 

JOPES  procedures  say  tliat  the  force  provider;-;  are  to  verify  that  passengers  and 
cargo  are  placed  on  the  piroper  planes  and  ships.  Tliis  is  the  way  it  had  been 
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done  in  exercises.  But  during  the  real  deplo\ment,  it  turned  out  that  FORSCOM 
could  not  have  rcpicsentatives  at  all  the  pickup  points  to  report  that  "x"  number 
of  troops  and  "y''  tons  of  cargo  from  unit  "z"  did  in  fact  depart  on  plane  "n"  at 
time  "t."  FORSCOM  tned,  but  could  not  keep  up. 

To  make  things  work,  USCINCCENT  gave  USTRANSCOM  the  mission  of 
collecting  the  manifest  data  and  entering  them  into  the  scheduling  and 
movement  deployment  database.  USTRANSCOM  did  this  by  tasking  AMC  to 
send  personnel  from  its  Inspector  General  (IG)  teams  around  to  all  of  the  pickup 
points  lO  make  sure  data  were  gathered  rind  entered.  This  worked  fine  after  a  bit. 
The  troops  loading  onto  the  planes  had  trouble  at  first  with  their  ULNs,  the  unit 
Ime  numbers  which  are  needed  to  relate  the  information  to  the  proper  JOPES 
data  record.^  Therefore,  the  word  had  to  be  spread  to  the  deploying  units  to 
make  sure  that  they  knew  their  ULNs,  and  then  to  be  sure  to  pass  them  on  to  the 
IG  representatives  as  they  departed. 

Initially  this  information  was  reported  by  secure  piione  to  AMC  HQ  where  it  was 
both  passed  in  an  AUTODIN  message  to  FORSCOM  and  manually  input  to 
JOPES.  After  a  few  days,  however,  the  second  task  was  seim-automated:  A 
patch  was  developed  that  allowed  the  information  to  be  input  (by  the  IG 
representative)  into  the  nearest  node  of  AMC's  command  and  control  system 
(GDSS)  and  then  passed  along  through  several  other  systems  into  JOPES. 

Early  sealifi  movements  suffered  similar  problems.  Equipment  may  have  been 
loaded  onto  trains  or  convoys  by  ULN,  but  once  it  reached  the  ports,  the  cargoes 
were  mixed.  MTMC  was  tasked  to  enter  the  ULNs,  tormages,  etc.,  of  cargo 
leaving  the  ports  into  JOPES,  but  had  little  mformation. 

Later  deployments,  especially  those  during  Phase  D,  were  better  organized.  As 
mentioned  in  the  previous  section,  installation  transportation  officers  were  able 
to  input  their  equipment  inventories  into  TC-ACCIS  and  to  create  LOGMARS 
labels  for  each  piece  of  cargo.  At  the  dock  then,  each  piece  of  ceirgo  loaded  on  a 
particular  ship  was  s'-anned,  identified,  and  automatically  entered  on  the  ship's 
manifest.  The  manifest  for  each  ship  thus  listed  each  piece  of  cargo  in  or  on  that 
ship.  A  copy  of  each  manifest  was  then  forwarded  to  the  seaport  of  debarkation 
(SPOD)  but  was  reportedly  not  too  useful  there  because  the  detail  was  not 
summarized  and  port  personnel  had  little  time  to  search  all  the  entries. 


^ULNs  serve  as  the  key  for  cataloging  TPFDD  recoros  in  JOPES.  but  the  Services'  primary  unit 
identifier  is  the  unit  ID  code  or  UlC  The  Deferue  Transportation  System  also  keys  on  UlC  for 
movement  idenhhcation.  The  JPEC  needs  a  viable,  automated  method  of  relating  UICs  to  ULNs  (and 
vice  versa). 
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For  lalor  deployments  MTNIC  was  usually  able  to  update  the  Scheduling  and 
Movements  database  witli  the  ULNs  dispatched  on  each  ship.  This  more 
aggregate  mtormation  was  more  meaningful  to  deplovment  officials  ’ 


Lack  of  Crucial  Capabilities  and  Interfaces 

Sometimes  it  turned  out  that  scheduled  troops  or  cargoes  were  late  m  arriving  at 
their  scheduled  POE  so  others  were  put  on  "their"  plane  or  ship.  Other  times, 
scheduled  planes  and  ships  broke  down  or  were  delayed  and  others  were 
substituted.  When  this  happened,  visibility  was  often  lost  as  lOPES  was  not 
designed  to  accept  tliose  types  of  changes. 


Correcting  Movement  Information 

In  theory,  CIKCs,  unit  commanders,  installations,  etc.,  can  querv’  JOPES  (the 
schedule  and  movements  [S&M]  database)  at  any  tmie  and  receive  up-to-date 
information  about  which  ULN's  have  been  moved,  on  which  aircraft  and  ships, 
and  how  the  actual  arrival  and  departure  dates  and  times  from  the  POEs  and 
rODs  relate  to  the  .ALDs,  LADs,  and  the  scheduled  arrival  and  departure  dates 
and  times.  JOPES  ls  even  designed  to  aggregate  information  and  to  show  the 
percentage  of  each  UIC  or  force  module  that  has  been  moved. 

However,  the  S&M  database  vv  as  designed  to  the  AMC  and  MSC  requirement 
that  they  be  given  five  and  30  days,  respechvely,  of  solid,  unchangmg  movement 
requirements  as  input  to  their  scheduling  activities.  .A,V1C  and  MSC  are  first 
supposed  to  put  vehicle  data  into  theS&M  database;  second,  "pull"  data 
concerning  troops  and  cargoes  from  the  requirements  database;  third,  to  do  tneir 
scheduling;  and  fourth,  to  push  the  scheduling  data  back  into  the  5&M  database. 
Finally,  the  deploy. ng  units  (or  .AMC  in  the  case  of  ODS)  manifest  specific  ULN's 
or  portions  of  ULNs  agamst  those  vehicles. 

That  information  is  then  not  supposed  to  change.  Fields  exist  for  actual  arm  al 
and  departure  times  to  be  input  after  tlie  movements  actually  occur,  but  no 
allowances  arc  made  for  changes  m  earners  or  m  routes.  If  someone  attempts  to 
ad)ust  a  movement  (for  example,  to  reflect  that  a  particular  UTN  actually  moved 
to  a  different  POD  tihan  it  had  been  assigned  to),  JOPES  will  simph,'  not  allow 
that  change  to  lie  made  unless  the  operator  goes  all  the  wav  back  ti'  the 


’.S-'.ite.  howi'vcr  thnl  .mlv  on-line,  real-lime  jccess  lo  Ihe  detailed  >liip  >  nijniteM  intorniiition 
Will  over  allow  pDs(  personnel  or  urtit  ci'intn.indcrs  U>  answer  qurstion:>  sucb  '  vvhicf)  shift  contains 
the  thrt‘t‘  radar  traiuanitters  lor  tiw  1  NorJ  AL>A?" 
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requirements  database  and  corrects  the  original  preferred  rt.')D.  This  means  that 
changes  occurring  vvithiin  the  three,  four,  or  five  days  before  a  movement  is  to  be 
made  will  not  be  reflected  in  the  database. 

This  reflects  the  design  (and  peacetime  use)  of  JOl^,  JDS,  and  JOl’HS  as  planning 
tooLs.  The)'  allow  lanly  movements  L  .at  pick  people  up  from  'where  the\'  arc- 
supposed  to  be,  move  them  directly  to  where  they  are  supposed  to  go,  and  then 
drop  them  off  there.'*  The  Chairman  of  the  Scheduling  and  Movements  Working 
Group  at  USTRj-XNSCOM  described  for  us  how  personnel  worked  around  this 
limitation  in  ODS,  and  how  tliey  now  hope  to  improve  the  database  and  the 
mterface  so  that  actual  movement  mformation  can  be  entered  direct!)  and 
without  replacing  the  descriptions  of  the  planned  movements. 


Using  Data  from  Existing  OPLAMs 

Another  problem  with  the  current  design  of  the  databases  is  tJiat  converting 
TTFDD  data  from  one  OPLAN  (theater)  format  to  another  is  difficult.  Planners 
at  U5EUCOM  told  us  that  as  they  were  converting  the  fort  e  lists  from  their  ma)or 
nlan  and  adantine  them  into  what  eventuallv  became  the  Eiirot  t-an  seinnt'nt  of 

i  *  KJ  .  4  c  ' 

USCENTCOM's  ODS  OPL.-VNl,  one  of  the  major  problems  was  m  con\'erling  the 
USEUCOM  ULN  structure  into  the  USCENTCOM  ULN  structure. 

USEUCOM  planners  eventually  got  around  that  by  taking  the  current  version  of 
their  plan,  pulling  off  the  forces  (ULNs)  that  were  needed  for  ODS,  and  calling 
this  part  by  an  mtermediate  name.  They  changed  the  USEUCOM  ULN  structure 
into  the  USCENTCOM  ULN  structure  and  then  called  those  resultmg  data  the 
first  draft  of  their  portion  of  the  USCENTCOM  plan.'’ 


■*Nole  that  lhc^<■  Jclioencii-s  c  j-rentlv  Jespili-  the  pri-M-na-  ot  Itie  "t '  for  exitulion  :r-,  ih.> 
rnnvm  )OPES 

LSCENTCOM  pcrv'nnt-l  ropt'rltsj  olhor  prabloins  with  Ul  anJ  forco  IXinr-n  th- 

war  pvfn,iini-  w.inliii  to  know  how  big  Ihi-  ni.’|or  tinils,  and  Ihp  divisions  m  parlioiiliir.  wori’,  hnw 
many  ana  what  tvpi-  ot  comp.inies  they  wen-  taking  along,  and.  vspivially.  when  ihvy  would  ikisi- 
That  intormation  however,  was  difficult  to  provide  It  remnrwi  either  (a)  the  use  and  maintenance  ot 
a  logical  ULN  structure,  or  (b)  the  construction  and  maintenance  ot  torce  modules  lliev  emphasized 
that  both  approaches  had  real  problems 

liven  in  deliberate  planning  where  thev  had  lots  of  lime  and  w  here  lew  things  ch.inge  il  was 
difficult  .M  r.AC.XF  several  vears  ago  a  database  for  a  particular  tiPL,\.N  was  set  up  using  Lorre 
McxJules  (FM)  to  di-scribe  tin-  organizational  structure  of  the  units  and  using  ULNs  to  descnhe  the 
tunctional  relationships  It  was  easy  to  set  up,  hut  as  the  data  evolvc\l  and  uniLs  were  dianged.  it 
quicklv  Kvame  very  complex  Lach  time  an  individual  unit  was  mined  into  or  out  ot  the 
deplovtnunt  ■‘c'gi'once,  planners  to  adiust  the  FM  II  one  individual  was  k-vping  track  of  the  tone 
module  and  another  individual,  say  at  a  component,  entered  additional  units,  those  units  could 
quic  kly  hc-cc-rne  lost  among  the  thousands  of  rixords  The  same  held  tor  the  ULNs 
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Those  were  some  of  the  major  problems  the  Army  expencnced  with  the 
deployment-plarmiitg  systems  during  ODS.  Those  and  more  need  to  be 
addressed  and  corrected  before  tlte  next  real  deplovTnent. 
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6.  Conclusions  and  Recommendations 


We  can  now  categorize  the  problenas  associateci  with  planning  for  Army  ODS 
deployments  into  two  broad  groupings:  (1)  problems  arising  because 
uncertaint  ;  inherent  in  ODS  (or,  indeed,  in  any  contingency)  require  enbeal 
skills  of  planners  and  deployment  personnel,  skills  thiat  prior  to  ODS  only  some 
had  practiced  and  few  had  mastered;  and  (2)  problems  associated  with  the  then- 
current  versions  of  the  computerized  support  systems. 


Uncertainties  Affected  Procedures 

During  peacetime  it  is  easy  for  planners  to  become  complacent,  get  wrapped  up 
in  their  scenarios,  contingencies,  and  plans,  and  real)  ,•  believe  that  thev  have  tlw 
answer  to  this  situation  or  that  problem.  It  is  easy  to  forget  that  we  do  not  know 
which  situation  or  problem  will  actually  occur  and  that  we  cannot  predict  how 
U.S.  commanders  will  respond  to  particular  situations  let  alone  how  opposing 
commanders  will  react  to  U.S.  initiatives. 

The  mindset  in  many  quarters  before  ODS  was  that  we  had  done  lots  of 
planning,  gone  through  many  exercises,  and  knew'  pretty  much  what  had  to  be 
done.  Unfortunately,  much  of  that  plarming  and  most  of  those  exercises  had 
evolved  over  the  years  into  simple  efficiency  drills  where  ali  uncertamties  had 
been  eliminated:  We  knew  exactly  which  troops  and  equipment  would  be  used; 
we  knew  when  those  troops  and  equipment  would  be  ready;  we  knew  when  the 
ships  and  planes  would  arrive  to  pick  them  up  (and  if  they  were  not  on  time  wo 
would  complain  and  call  "foul");  w'e  sometimes  had  even  studied  just  how 
tightly  to  pack  each  piece  of  equipment  into  a  particular  ship.  But  a  crisis,  by 
definition,  is  not  like  tliat.  In  a  crisis  we  must  not  only  know  how  to  execute 
under  real-time  pressures,  we  must  also  know  how  to  plan  so  that  we  can  create 
and  constantly  adapt  deployment  and  employment  plans  under  those  same 
pressures.  We  must  know  how  to  plan  in  emergency  situations,  not  just  how  to 
plan /or  < r.rgency  situations. 

At  the  beginning  of  OD5  some  personnel  were  familiar  with  deliberate-planning 
prcKedures,  some  were  familiar  with  crisis-action  planning  procedures,  and  a 
few  were  familiar  with  both.  But  very  few  had  experience  in  working  in  real 
time  to  simultaneously  plan  and  execute  the  deployment  of  a  large  military  force. 
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Desert  Shield  differed  from  the  training  and  practice:  There  was  no  early 
warning,  no  plan  on  the  shelf  ready  to  execute,  and,  in  the  bcginnmg,  not  even  a 
good  idea  of  the  Army's  mission  or  of  how  manv  soldiers  might  bo  needed. 
Planners  had  to  improvise  and  build  constantly  evok  ing  emplovmcnt  lUid 
deployment  plans  at  the  same  time  that  their  colleagues  were  ph\  sicallv 
transporting  tlie  inihal  combat  and  support  units. 

USCENTCOM  had  no  OPl^yVN  and  TFFDD  it  could  pull  off  tlie  shelf.  It  had  been 
building  a  new  and  surprisingly  appropriate  plan  but  was  months  awav  from 
comple'ion.  Tlie  automated  deployment-planning  systems  designed  to  facilitate 
data  creation,  exchange,  and  visibility  were  being  updated;  Versions  1  and  2  of 
JOPES  had  recently  been  fielded  and  not  all  personnel  were  familiar  with  the 
look,  the  operation,  or  even  the  concept  of  the  system,  other  joint  and  service- 
specific  support  sy.items  were  evolving  m  similar  if  less  radical  fashions. 

Nearly  all  ol  the  plaruiing  activities  and  exercises  that  deployment  personnel  had 
been  througli  had  assumed  that  (a)  the  threat  and  the  proper  U.S.  response  to  the 
threat  (and  thus  the  mussion  for  the  Army  and  other  Services)  were  clearly 
defined;  (b)  the  forces  necessary  to  handle  the  crisis  and  the  transport  they 
required  were  obvious;  and  (c)  the  ma|ority  of  the  transportation  resources  of  the 
nation  were  immediately  available  to  the  military.  ODS  differed  significantly 
from  those  activities 

•  There  was  uncertainty  concerning  Iraqi  capabilities  and  intentions;  Would 
Iraq  attack  Saudi  Arabia  immediately,  or  wait?  t\'hat  tactics  would  be 
employed?  Would  chemical  or  biological  or  nuclear  weapon:-,  be  used? 

•  There  was  uncertainty  concerning  U.S.  capabilities  and  mtentions:  What 
capabilities  were  required  to  counter  each  of  tlic  potential  threats?  Was  there 
j  robust  combination  of  capabilities  we  could  field?  Which  units  could  be 
ready  for  deployment?  Under  what  schedule^  How  much  lift  would  be 
available'’  When’  W  hat  type  of  .support  units  were  needed?  When?  Wlio 
should  furnish  them? 

•  Pinally,  within  that  conte.xt  there  was  substantial  uncertamtv  concerning  the 
proper  and  efficient  real-time  u^e  of  the  deployment-planning  procedures 
and  support:  How  can  vve  plan  and  execute  at  tie'  same  time?  How  can  we 
v.'ork  at  two  levels  (with  details  h’r  the  units  currently  deploying,  wiUi 
aggregates  lor  those  to  deploy  In  two  wee  ks)  smiultaneouslv’  Who  sources 
the  comlidt  units?  The  support  units?  Who  vali.lates  tiu'ir  readiness  and 
availability?  Is  it  really  necessary  to  provide  centralized  vi.sibihty  of 
manifesting  and  mov  ement  infonnatiun? 
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Thus,  the  uncertainties  inherent  in  the  threat  and  in  our  responses,  combined 
with  a  lack  of  practice  with  and  trust  in  official  procedures,  provided  significant 
challenges  to  Army  planners.  A  critic  might  say  that  the  success  of  the  ODS 
deplov'menLs  was  due  as  much  to  the  caution  and  inephtude  of  the  enemy  as  to 
the  quality  and  performance  of  our  personnel,  procedures,  and  support.  A  fairer 
depiction  suggests  that,  despite  lack  of  comparable  standards.  Army 
deployments  were  planned  and  executed  reasonably  quickly  and  smoothly,  and 
were  possible  (on  such  a  scale  and  schedule)  primarily  because  of  the  intelligence 
and  can-do  attitude  of  the  persormel  and  the  existence  of  modem  planning 
procedures  and  computerized  irJormation  flows.  This  depiction  also  suggests 
that  ODS  experiences  provide  insights  into  a  number  of  problems  and  issues  for 
further  research. 

Uncertainties  will  always  be  present  and  can  never  fully  be  controlled.  We  must 
never  exjiect  to  experience  a  contingency  that  fits  perfectly  with  some  plan  that 
has  tfioroughly  been  worked  through  and  documented — we  will  always  fmd 
some  discrepancies.  On  the  other  hand,  we  should  never  expect  a  pure  no-plan 
crisis.  Portions  of  exLSting  plans  and,  as  time  goes  by,  more  and  more 
prepackaged  combat  and  support  modules  will  be  available.  The  challenge  is 
first  to  learn  to  plan  genetically  and  then  to  learn,  to  work  mteractively  to 
integrate  and  improve. 


Support  Systems  Hindered  Operations 

JOPES  and  the  other  systems  were  crucial  to  ODS  deployments.  They  allowed 
establishment  of  tlie  common  database  that  provided  the  JPEC  with  visibility  of 
the  day-by-day  progress  of  the  deployment.  If  this  capability  had  not  been 
present,  or  had  not  been  present  on  the  scale  of  JOPES/ WWMCCS,  the  ODS 
deployments  would  have  taken  substanticilly  longer  cind  the  frustration  level  of 
the  JPEC  would  have  been  substantially  higher. 

Nevertheless,  definite  problems  emerged  during  ODS.  JOPES,  the  Joint 
Operation  Planning  and  Execution  System,  may  someday  fully  support  the 
planning  and  execution  of  mobilization,  deployment,  employment,  and  resupply 
activities  as  its  plan  specifies,  but  during  ODS  and  for  at  least  the  next  several 
years,  it  locuses  on  deployment  and,  especially,  on  planning.  Current  versions  of 
JOPES  rely  on  older  JOPS  and  JDS  capabilities.  Designed  to  be  the  primary 
wartime  command  and  control  system  of  the  NCA  and  the  CJC5,  JOPES  also 
carries  much  of  the  detailed  cargo  and  movement  information  needed  by  force 
commanders  tind  transportation  managers. 
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At  the  beginning  of  ODS,  some  people  were  familiar  with  JOPS  deliberate- 
planning  applications;  some  people  were  familiar  with  JDS  deployment-planning 
applications;  and  a  few  people  were  familiar  with  the  JOFES  interface  for  JOPS 
and  JDS.  But  ver\'  few'  had  experience  in  using  JOPS  and  IDS  together  to 
simultaneously  plan  and  deploy  a  large  militar\'  force. 

Consequently,  during  ODS  few  people  used  the  planning  and  analysis  tools 
available  in  JOPES.  Those  tools  can  w'ork  w'ith  either  nohonal  units  or  actual 
units,  so  that  once  the  major  combat  units  for  the  inihal  deployments  were 
identified  (and  that  happened  quite  early),  JOPES  could  have  been  used  m  its 
notional  mode  to  estimate  the  support  and  resupply  required  by  those  combat 
units  as  well  as  the  transportation  feasibibty  of  the  total  package.  The  Joint  Staff 
did  use  notional  units  to  estimate  the  number  of  reserve  ships  that  might  bt 
needed  under  various  "what-ifs,"  but  most  of  the  organizahons  focused  on 
acquiring  and  mputting  detailed  data  after  particular  units  had  been  selected  for 
deployment  or  simply  waited  until  others  had  mput  those  data.  That  is,  because 
they  addressed  transportation  requirements  only  from  the  bottom  up,  most 
organiz' tions  were  not  able  to  provide  even  rough  estimates  of  aggregate 
transport  requirements  until  all  the  detailed  data  were  coCected  and  input.  Most 
high-level  planning  was  done  without  benefit  of  existing  planning  tools,  tools 
that  if  used  effectively  could  have  substantially  reduced  the  confusion  and 
disorganization  that  occurred,  especially  in  the  first  weeks  of  the  operation. 

Focusing  on  the  way  the  support  systems  actually  were  used  m  ODS,  four 
general  types  of  problems  have  been  described  in  this  report. 

•  Unfriendly,  overloaded  support  systems  resulted  in  slow  and  incorrect  data 
entries. 

•  Problems  with  the  design  and  control  of  the  deployment  databases  resulted 
in  the  loss  o>  significant  amounts  of  previously  entered  data,  slowing  the 
creation  of  databases  and  reports  and  reducing  their  usefulness. 

•  Procedures  for  collecting  and  entering  crucial  information  into  the  support 
systems  had  not  been  well  tlioughl  out  beforehand. 

•  The  support  systems  lacked  several  crucial  capabilities  and  mterfaccs. 

The  first  two  types  of  probierns  were  ubiquitous.  Every  organization  reported 
shortages  of  JOPES  operators  and  supervisory  personnel.  Every  organization 
agreed  tliat  tlic  military's  automated  information  systems  were  relatively 
inflexible,  not  user  friendly,  and  negligent  m  assuring  data  mtegntv  and 
consistency.  These  problems  slowed  suppeirt  to  ODS,  frustrated  personnel 
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involved  in  data  input  and  systems  operation,  and  probably  delayed  some 
deplovTnents. 

The  latter  bvo  types  of  problems  had  more  severe  repercussions,  especially 
during  the  first  several  months  of  the  deployments.  Because  recent  exercises  had 
not  realistically  portrayed  the  difficulties  of  collecting  and  inputting  data  during 
no-  and  low-plan  operations,  some  crucial  procedures  were  ill  defined  and/or 
allocated  to  inappropriate  organizations.  Also,  because  the  support  systems 
emphasized  planning  more  than  execution,  important  information  on  unit, 
vehicle,  and  movement  changes  still  could  not  be  entered  directly.  These 
problems  resulted  in  some  transporters  not  knowing  what  thiey  were  supposed 
to  move,  some  unit  comm2mders  not  knowing  the  status  and  sometimes  even  the 
location  of  their  units,  and  some  in-theater  organizations  not  knowing  what 
personnel  or  equipment  would  arrive  on  the  next  ship  or  plane. 


Recommendations 

By  the  end  of  the  ODS  deployments,  people  had  been  trained,  procedures  had 
been  debugged,  and  systems  had  been  patched.  In  this  sense,  and  because  the 
enemv  mounted  few  effective  operations,  ODS  can  be  viewed  as  a  valuable 
learning  expenence.  If  called  upon  to  replicate  those  deplo>ments  today,  the 
Army's  actions  and  reactions  (and  indeed  those  of  all  the  U.S.  Services  and 
defense  organizations)  would  be  substantially  faster  and  smoother.  However, 
the  knowledge  gained  from  ODS  will  degrade  with  time  as  people  transfer  and 
organizations  change.  The  challenge  is  to  learn  and  to  generalize — to  leam  from 
ODS  the  improvements  in  procedures,  systems,  and  practices  that  can  be  used 
effectively  in  future,  dissimilar  crises. 


Procedures 

Perhaps  the  most  important  lesson  from  ODS  is  that  we  need  to  re-examine  how 
we  do  deployment  planning  and  execution  in  the  post-Cold  War  era  where 
unexpected  and  unplarmed-for  regional  crises  now  pose  the  most  probable 
threats  to  tlie  U.S.  security  and  weU  being. 

ODS  demonstrated  that  political  sensitivities  easily  can  cause  mitial  plannmg 
activities  to  be  close-held  at  the  NCA  and  CJCS  level,  foremg  lower-level 
organizations  either  to  bide  time  or  to  initiate  earlv  plannmg  without  clearly 
stated  missions  or  objectives.  Even  after  the  majority^  of  the  JPEG  was  allowed 
access  to  ODS  plannmg,  however,  major  unccrtamtics  continued  because  the 
CINC's  priontics  changed  almost  daily  in  response  to  changing  perceptions  of 
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the  world.  The  real  Lssue  is  that  ODS  is  probably  not  an  unusual  scenario  in  these 
times  and  that  many  or  most  future  contingencies,  at  least  at  the  beginnmg,  will 
ha\'e  strong  elements  of  unceitamtv"  and  secrecy. 

Accepting  that  as  the  norm  suggests  that  procedures  for  deployment  planning 
should  be  repackaged  to  emphasize  flexibilit\'  and  adaptability.  Deliberate- 
planning  activities  should  emphasize  detailed  planning — not  for  completeness- - 
but  withui  the  contexts  of  leammg  how  to  plan,  how  to  establish  relationships 
with  other  planning  and  execution  organizations,  and  how  to  acquire  familiarity 
with  foreign  regions  and  their  customs  and  re.sourccs.  Crisis-planning  activities 
should  stress  and  facilitate  concurrent  planning  and  execution;  they  should 
acknowledge  that  most  crises  will  require  either  a  new  OPLAN  and  TPFDD  or,  at 
the  least,  immediate  and  significant  changes  toexistmg  but  dated  plans  and 
databases. 

Crisis-action  prixredures  must  stress  multilevel  planning — the  use  of  aggregate 
data  to  estimate  first-round  needs,  capabilities,  and  possibilities,  followed  by  the 
use  of  detailed  data  to  plan  and  execute  actual  movements.  ODS  oflicials 
commonly  worked  with  three  and  four  levels  of  data.  They  used  aggregate 
(force-level  and  unit-level)  data  in  much  of  their  planning,  in  communications, 
and  in  situation  reporting;  they  used  more  detailed  (ULN-level)  information 
whenever  they  were  involved  with  JOPE5  and  its  applications,  and  they  used 
even  more  detailed  information  (at  the  piece  and  person  level)  in  planning  and 
executing  the  actual  moves.  That  experience  needs  to  be  incorporated  mto 
manuals  and  training. 

Planners  must  be  taught  to  expect  uncertainty,  to  expect  to  initially  receive  less- 
than-accuratc,  Icss-than-complete,  constantly  changing  information,  and  to 
expect  to  work  initially  with  rough,  aggregate  tools  In  the  first  days  of  a  crises, 
especially  one  without  well-defined  objectives,  high-level  planning  should  be 
based  on  generic  information  on  mission  type,  time  window,  task  force,  and 
transportation  allocation.  The  initial  goals  should  be  to  develop  strategic  options, 
estimate  force  and  transport  requirements,  and  establish  realistic  time  windows. 
This  will  involve  negotiations  among  high-level  officials  and  planners  it 
aggregate  analvses  indicate  the  postulated  resources  cannot  handle  the  required 
operations  within  the  time  wimfows.  As  early  as  possible,  the  CINC  should 
establish  a  priority  list  and  task  the  S<.>r\'ices  to  select  comhat  units  and  prioritize 
their  moves. 

Tfien  as  planning  priKeeds  downward,  it  necessarily  becomes  more  detailed  and, 
at  the  unit  and  command  levels,  the  data  flow  and  analvses  should  work  from 
the  detailed  to  the  aggregate,  from  llie  bottom  up.  Summed  information  from 
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the  units'  detailed  plannmg  can  then  be  used  as  a  check  against  the  aggregate 
estimates  from  the  higher-level  planning.  If  the  aggregates  are  not  within 
tolerance,  then  officials  must  negotiate  changes  at  the  unit  level  and/or 
reconsider  the  higher-level  plans. 

Additional  improvements  and  enhancements  to  procedures  suggested  by  the 
ODS  experiences  include: 

1.  Development  of  tailorable  force  packages  for  both  combat  and  support  units 
at  all  levels,  complete  with  equipment  lists  and  stow  plans. 

2.  Development  of  doctruie  and  instituhons  for  the  command  and  control  of 
support  organizarions  and  for  support  packages  for  different  classes  of 
contingencies  and  different  types  of  theaters. 


Systems 

Army  expenences  m  ODS  suggest  that  the  computerized  deployment-support 
systems  need  to  be  refocused  and  updated.  At  the  highest  level,  planners  at  the 
NCA,  CJOS,  supported  CFNC,  and  USTRAN55COM  need  automated  tools  for 
planning  and  gaming  (in  the  form  of  what-if  scenarios,  based  on  the  CINC's 
evolving  OPLAN  or  COA)  as  aids  in  decisionmaking.  They  must  have 
immediate  access  to  aggregate  planning  tools  that  can  operate  with  incomplete, 
preliminar)'  information.  They  must  have  means  for  continually  incorporating 
newer  and  more  complete  information  and  plcinning  guidance  into  their  analyses 
and  prelimmary  plans.  Meaningful  links  must  be  developed  between  elements 
of  information  as  they  become  available  and  are  updated;  that  mformation  must 
be  maintained  in  a  database  from  which  selected,  relevant  subsets  can  be 
furmshed  to  the  JPEC. 

As  the  planning  proceeds,  means  must  be  developed  for  linking  the  several 
levels  of  data — forces,  units,  ULNs,  and  persons /pieces — so  tiiat  planning  and 
deployments  can  be  conducted  effectively  and  efficiently  by  the  operating  and 
transportation  corrunands  and,  at  the  same  time,  monitored  and  coordinated  by 
tlie  higher-level  commands.  How  the  systems  and  databases  should  be 
integrated  or  intercopjiected  is  an  open  issue,  but  it  must  not  be  a  simple  bottom- 
up  system;  both  national  officials  and  mid-level  planners  must  be  able  to  specify 
and  analyze  force-  and  unit-level  operations  whether  or  not  ULN  and 
person /piece  data  arc  available. 

Simuarl;,',  rnuai. .  .nusi  b..  uev..l..,j.,i  d  h .  linkmg  the  several  levels  of 
communications  so  that  planning  and  deployments  can  be  conducted  bv  the 
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operating  and  transportation  commcinds  and,  at  the  same  time,  monitored  and 
coordinated  by  higher-level  commands. 

Additional  actions  the  Army  might  take  to  upgrade  its  deployment  capability 
include; 

1.  Offload  Army-specific  functions  from  computers  used  for  deployment 
planning  and  execurion. 

2.  Improve  the  user-friendliness  of  Army  deployment-support  systems  and 
Army  interfaces  into  the  joint-deployment  systems. 

3.  Procure  portable  deployable  hardware  that  allows  deploymg  commands  to 
maintain  contact  with  the  JPEG  and  to  continue  their  planning,  analysis,  and 
control  activiries  as  and  after  they  deploy. 

4.  Work  with  the  Joint  Staff,  Defense  Information  Systenris  Agency  (DISA), 
USTRANSCOM,  and  the  deployment  community  to; 

A.  Develop  methods  for  overcoming  the  over-writing  and  other  p'roblems 
associated  with  the  lack  of  concurrency  control  m  the  current  JOPES 
databases. 

B.  Determine  more  appropriate  and  produchve  means  for  (1)  providing 
Army  units  with  up-to-date  visibility  of  deployment  databases  and  (2) 
providing  the  transport  community  w'ith  more  direct  access  to  units' 
equipment  inventories  without  usurping  FORSCOM's  responsibilities 
and  witFiOut  overloading  JOPES  and  WWTdCCS. 

C.  Develop  means  for  linking  planning  ULNs  to  the  actual  progress  of  the 
deployment  in  order  to  ensure  visibility  throughout  the  entire  process  as 
well  as  to  support  later  operahons  and  analysis.  Often  several  ULNs 
need  to  bt  tied  to  one  transport  carrier  identifier  and  perhaps  as  often  a 
smgle  UL.N  becomes  split  across  several  carriers.  Detailed  data  systems 
must  'entify  tlie  portion  of  the  requirement  bemg  transported  by  each 
came  . 

D.  Develop  procedures  wilhm  the  data  systems  for  more  efficiently  rolling- 
up  ULN  (JOPS  Level  1  arid  2)  data  to  the  UIC  and  force-module  level  and 
for  standardizmg  and  reconciling  JOPS  Levels  3  and  4  data  with  the  even 
more  detailed  mfoimation  available  from  f  C-ACCIS  and  the  A.MC  and 
MTMC  data  systems.^ 


^Plans  for  L'STR.'W'SCOM  s  Global  Iransp  irtation  Neliwirk  iiuv  im  ludi'  the  Idllur  tasks 


E.  Express  aggregate  as  well  as  specific  cargoes  ui  square  feet  as  well  as 
tons  to  facilitate  sealift  planning. 

Most  important,  however.  Army  and  JPEC  personnel  must  realize  that  for  the 
foreseeable  future,  regardless  of  near-term  or  even  mid-term  improvements  in 
the  support  systems,  those  systems  w'ill  conhnue  to  exhibit  deficiencies  and 
shortfalls  and,  in  particular,  that  there  will  always  be  delays  in  getting  up  to 
speed  fast  enough  in  no-  and  short-warning  crises.  High-stress  activities  such  as 
bringing  svstems  up  to  speed,  creating  and  improving  databases,  and  working 
around  bottlenecks  and  deficiencies  will  continue  to  challenge  crisis-action 
procedures,  systems,  and  personnel. 

Personnel 

If  we  accept  the  prentises  that  future  crises  wiU  usually  arrive  unannounced  and 
that  planning  and  support  systems  wdl  continue  to  evolve  rapidly — constantly 
improving  and  expanding  capabilities  and  constantly  challengmg  operator 
skills — then  the  most  critical  element  of  the  deployment  planning  system  will 
continue  to  be  its  personnel;  the  soldiers  and  civilians  who,  with  vvhate%  er  tools 
are  then  available,  must  quickly  and  correctly  plan  operations,  select  units  for 
deployment,  pass  along  cargo  infotmation,  and  supervise  moves  and 
employments.  To  better  train,  nurture,  and  reward  those  personnel  the  Army 
should: 

1.  Strengthen  career  paths  for  planning  personnel.  Increase  recognition  of 
superior  skills,  qualifications,  cind  performance. 

2.  Increase  the  training  and  practice  of  those  personnel  m  realistic-plan,  no¬ 
plan,  and  unexpectedly  stressful  scenario;.  Restructure  deplovTnenl 
exercises  to  require  personnel  to  u.se  the  deployment  support  systems  to  their 
maximum  capabilities,  including  the  rapid  compilation  of  large  TPFDDs  and 
the  rapid  analysis  and  mtegration  of  situational  changes. 

3.  Create  ways  to  use  crisis-planning  tools  m  day-to-day  peacetime  operations. 
Th  is  will  be  difficult,  but  it  is  necessary  to  ensure  familiaritv  and  continuing 
competence. 

4.  Civilians  should  be  trained  as  JOPES  operators.  During  high  demand 
periods  contractors  should  be  u.scd  to  augment  tliis  stabilized  workforce. 
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Appendix 

A.  Joint  Planning  Support  Systems 

This  appendix  contains  information  on  the  joint  planning  systems:  JOP5,  JDS, 
and  JOPES.  It  begins  with  a  brief  historical  overview  and  then  provides  more 
detailed  discussions  of  the  VVWMCCS  and  the  three  planning  systems. 

A  Brief  Overview 

The  routine  use  of  data  processing  for  military'  plannmg  began  in  the  1960s.  Soon 
after,  it  became  apparent  that  different  types  of  computers,  incompatible 
software,  and  inconsistent  planning  procedures  and  documentation  made  it 
difficult  to  commurucate  between  commands.  To  address  these  problems,  work 
began  in  1967  on  the  development  of  a  new  plannmg  system.  By  1973,  35  new 
Honeywell  6000  computers  had  been  installed  as  part  of  the  \\T»TvlCCS  to 
furnish  ADP  support  for  the  new  planning  system.  Unfortunately,  many 
applicahon  programs  were  incompatible  with  the  new  computers.  To  remedy 
the  situation  the  Joint  Chiefs  of  Staff  directed  the  rapid  development  of 
temporary  computer  programs  until  new  software  could  be  introduced.  Four 
efforts  were  designed  and  developed:  the  Force  Requirements  Generator  (FRG) 
to  build  cind  time-phase  a  force  list;  the  Movement  Requirements  Generator 
(MRG)  to  compute  the  support  required  to  sustain  a  military  force;  the 
Transportation  Feasibility  Estimator  (TFE)  to  simulate  the  strategic  deployment 
of  forces  and  support;  and  the  utility  programs  to  allow  the  other  programs  to 
communicate  emd  produce  a  meaningful  OPLAN  database.  These  programs 
worked  so  well  that  they  were  adopted  as  the  standard  AI5  for  joint  operation 
planning.  In  1975,  JOPS  Volume  HI  was  published,  describing  the  JOPS 
computer  support  system  often  referrea  to  as  JOPS  HI.  JOl’S  IH  has  undergone 
many  updates  since  its  origirial  version. 

In  1975-1976,  a  small  number  of  WWMCCS  computers  were  interconnected  in  a 
Prototype  WWMCCS  Intercomputer  Network  (PWIN)  fashioned  after  the 
ARPANET.  In  the  1978  NIFTY  NUGGET  exercise,  a  new  version  of  JOPS 
software  and  network  programs  was  hosted  on  WW'MCCS  to  simulate  a 
deployment  exercise  involving  the  mobilization  of  reserve  forces.  When  the 
computers  and  communications  systems  were  overloaded,  and  proved  unable  to 
perform  the  tasks  required  m  tlie  hme  available,  urgent  demands  were  made  to 
modernize  the  WWMCCS. 


In  thn  Offu'c  ot  tho  jnint  Chic'is  ul  St.ill  crcatL'd  tiu'  Jnint  Ucj'lovnK'iit 
A^cika’  tu  ci'i'.triili/i,’  innbilizatinn  and  dcf'lnvmcnt  planning  aiui  direct 
development  of  an  automated  system  to  support  deployment  pianninp  and 
exi-eution  Hie  result  was  the  Joint  Deplovment  S\  stem  (JDS)  U)r  erisis-aetion 
planning  In  tlu-  same  year,  a  ('lAO  study  recommended  that  a  VVWMCt  S 
pro)eet  manager  position  be  created  with  responsihilits'  tor  all  WVA'MCCS  and 
VVVVMCCS-related  computer-based  inlr)rmation  systems,  as  well  as  the  authority 
to  implement  necessarc’  changes.  In  ri'sponse  to  the  GAO  report,  DoD  Directn c 
5100.57  created  a  VVU’MCCS  Flngineering  Organization  as  .)  sep.irati-  entity 
within  the  Dek-nsi' C'omnuinicatu>ns  Agera  V.  The  I’ROLil)  SI’IKl  I  ecercise  m 
lOHt),  howeviT,  again  indicated  there  had  been  no  major  inipri'yement  m 
pertormance,  di'spite  major  investments  m  jl^  and  m  the  computer  ni'tvvi'rk. 

In  T)K1,  the  I  )on  and  ji'int  C  hiefs  of  Statl,  in  an  effort  to  ciirrect  planning-  and 
execution-related  deficiencies,  formed  a  Jiunt  IManning  and  hxecution  Steering 
Committei',  under  the  direction  of  j-5,  and  assigned  it  thi'  task  ot  oversi’eing  a 
rex  lew  of  the  planning  <md  execution  process.  In  JiiK  l'-tS2.  the  Operation 
I'lanning  Stei'ring  (iroup  (Ol’SC'd  w,is  tiirmed  to  give  periiKinenl  flag  and  general 
officer  directum  to  thi'  di‘yelo[iment  of  follow-iin  s\  stems  to  JOTS,  )1  )S,  and 
VVVVMCX'S.  A  timetable  was  established  tor  the  improvement  ot  the  VVVVMCt  'S 
Information  System,  with  development  between  lMiS2  .md  1SK5,  tc'sting  beginning 
in  1985,  <md  implementation  beginning  in  l9Hh,  to  •ittain  partial  operation  by 
19H8  ..\s  part  of  this  effort,  the  jOI’F.S  Kei|uired  (.tper.itional  C'apabihtv  was 
appri'ved  on  July  5,  1983. 

As  a  ri’sult  of  the  Cold water-Nichols  Dol)  Kiuirgamzation  .Act  of  !9Sf),  the  JCS  J-7 
Opi'r.itional  Plans  and  Inferoperabilitv  OireCtor.ite  w.is  formed  and  is  luux  the 
prixponent  for  JOI’hS.  TIh-  OI'SUI’s  (oj'erational  deputies,!  serve  .is  the  priiu  ip.il 
policy  guidance  body,  replacing  the  ktl’Sh.  The  new  US  I  K.ANSCC^M  was  to  act 
as  the  impleimmting  agency  lor  CJC'S/ |C  S  ap[mo\  ed  !(.  )IT'S  polu  v,  .is  well  as  .i 
conduit  for  usiT  input  llie  VVVV.MCCS  upgr.iding  effort  became  known  as  W'lS, 
with  the  Air  l  orre  the  desigeati'd  le.ul  agent  I  he  .Air  l  orce  dev  eloped  a 
c  oiiijirehensive  pirogram  that  involved  rej'lacement  of  hardw.ire  and  software 
but  Inidgetarv  constraints  caused  a  redirection  oi  the  etfort. 

Ill  tIu-  sj'ring  of  logo,  btu  ause  ot  iik  osising  high-lev  el  I  rusti  ation  with  the 
progress  ot  the  program,  thi-  Ueiense  t ’omiiuinicat ions  .Ai',ene\  (i  X  .-X), 
speciticall  v  the  joint  I  .tat a  Systems  Support  (  enter  (  I  I  tSSC  i,  vs  as  g,i'.  en  out;  ol  ol 
that  p.irt  o!  the  WlS  program  th.il  v.as  loiui-rned  w  itli  )(>rs,.  Jl  is  moderni.Mtion 
VVIS  leased  to  exist,  .iiiii  DC.A  has  design. ilcv!  its  i  tlort  the  W'VViMC  (  S  .-M  tl' 
Modernization  tV\'.-\.M ) 
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WAM  vvas  designed  to  remedy  existing  doiiciencies  in  command  and  control 
systems,  e  g.,  lack  of  efficient  stand,  rd  force  status  capability,  lack  of  automated 
support  for  no-plan  and  multiplan  situations,  and  lack  of  an  on-line  pian 
mi'dification  system.  The  JOPES  requirements  were  the  principal  fiKiis  of  the 
WAM  effort.  Those  requirements  were  to  be  satisfied  through  new  applications 
software,  new  procedures,  an  integrated  database,  ana  improvements  to  the 
WWMCCS  Standard  ADP  baseline  as  approved  by  the  WAM  management 
structure.  The  initial  program  focus  was  on  the  crisis,  deliberate,  and 
conventional  deplovment  planning  and  execution  tasks.  Tlie  software 
development  was  to  be  modularized  into  a  series  of  versions,  the  first  of  which 
tied  together  JOPS  and  JDS  with  a  common-user  interface.  In  N'ovember  1084 
JOPES  Version  1  was  released,  followed  bv  Version  2  in  .April  1990,  and  Versiim  .S 
m  December  1990. 

The  Macintosh  workstation  was  designed  to  be  an  integral  part  of  the  W.AM  and 
a  hardware  platform  for  parts  of  the  Wy\M  program  to  support  distnbuted 
picKessing  of  JOPES  programs.  It  would  mterface  the  user  wnth  all  host-based 
ser\'ices.  Operational  assessment  of  Version  -1,  however,  was  disappointing  and 
led  in  the  summer  of  1992  to  the  suspension  of  most  JOPES  development  efforts. 
Ihe  following  section  discusses  these  topics  in  more  detail. 

The  WWMCCS  Concept' 

Ihe  World-Wide  Militar\’  Command  and  Control  System  (WWMCCS)  is  defined 
in  Joint  Pub.  0-2,  Untped  Action  Armed  Forces,  as  "tlie  system  that  prowdes  the 
means  for  operational  direction  and  technical  administrative  support  inc  olved  in 
the  function  of  command  and  control  of  U  S.  military  forces."  WWMCCS 
furnishes  a  multipath  channel  ot  .secure  communications  to  transmit  tactical 
warning  and  intelligence  information  to  the  Prcsid  nt  and  Secretary  ot  Defense, 
and  a  channel  from  them  to  give  direction  to  U  S.  combatant  commanders  The 
si  stcm's  goal  ;s  to  establish  effective  connectivity  among  the  members  of  the 
defense  organization. 

WWMCCS  IS  made  up  of  the  National  Military  Coniniand  Svstem  (NMCS),  the 
command  and  control  systems  of  the  unified  and  specified  comniands,  the 
WWMCCS-related  management  /  information  systems  of  ttic  militarv 
departments,  the  command  and  control  systems  of  the  headquarters  of  the 
Service  component  commands,  and  the  command  and  control  support  system.^  ot 
DoD  agencies.  The  priiiuii'v  mission  of  WWMCCS  is  tosu[u'ort  tho  national- 
level  command  and  control  function.  On  a  nuiunteifereiue  basis,  the  system  is 

'  Tills  in  J  If  rid  I  IS  idkt-n  (rum  AI-^'  I’uh  1 ,  pp  3-!4  m  S-24 
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.u  ailiiblo  to  support  conibutaiit  conmi.iiiiit'rs  in  tlu’ir  coinniaiui  and  cotitrol 
responsibilities. 

Coiuep^tuall)’,  VVWMCCS  ineludes  'ive  basic  elements:  tactuMi  warning  s\  stems, 
eommunieations  c.ipabilities  to  ci>neev  inli>rnr.itu>n,  bold  conk‘r(.  nei's,  .iiul  issue 
orders;  data  collection  and  bandlinj;  to  support  WVVMCCS  inkn  niation 
requirements;  executive  aids  for  usinp  the  VVWMCCS,  and  VVWMCCS  command 
facilities  (primar)'  or  alternative  command  centers).  The  WVVMCCS  supports 
four  "functional  families"  of  command  and  control  applications:  Resource  and 

I. 'nit  Monitorinp  (RUM;.  Conventii'iial  I’lamiinp  and  1  xecution  it-'I’I’),  Muclear 
Planning  and  Executii'n  (KPE),  arid  Tactical  Warning,  Attack  Assi’ssment 
(TW/AA). 

The  JOPS  System 

Before  November  ivb'-),  deliberate  plannin);  was  suf'ported  by  the  JCtPS  and 
crisis  tion  planning  bv  the  JDS.  jC)PS  is  an  ordereil  aiui  comprehensive  set  ol 
jiroci'dures  to  trar.slate  an  .issignesl  task  into  a  plan  ol  operations.  It  can  be  used 
to  develop,  rev  iew,  and  execute  global  and  regional  plans.  JOPS  is  a  WWMCt.':'' 
si.an.dard  com.puter  based  svsteni  usevi  in  Ib.e  delibcrat"'  planning  procesii  bv 
members  of  the  JPEC  to  develop,  analyze,  refine,  revie'v ,  and  maintain  .in 
OPLAN  and  to  prepaie  supporting  pl.'.ns.  T  he  Joint  D.d.i  Set  vice  Sup)H>ri  Cenlei 
has  been  responsible  for  supporting  and  inai'it.unir.g  JOl’S. 

During  crisis  or  time-sensitive-  plannm;;,  as  sfiowr,  m  Eigo.e  OPORDi  in.iy 
evolve  from  an  existing  C.M’LAN',  tmm  a  CC.'cJ’.'.Arv,  oi  from  a  iu.-p!an  situabon. 
The  JDS  supports  the  crisis-aAion  pi.mmng  priKcdures  by  prov  iding  Hie 
capalulity  to  liandk'  iiif'.irnMlion  r.ip-i  Jiv  du:  mg  c.  i  risis  it  bri.lges  die  g.ij 
bi’tween  delilu-iate  (>Iaoning  and  erna:.  exec. Cot. r.  bv  ensuring  tli  ”  .1  joint  ( ll'l-.W 
V".  itli  I'.s  associated  I  I’PDD  v  an  l>i'  I' .ir.s;ti(>ned  r.ipidiv  into  an  ex..'cut.ibk' 
t  iPOKD,  wluv  'll  V  .in  be  ini'uitorevi  vhiring  exeeution.  I  lie  v  .b- 1  K  -W-sp  r  )M  !  ms 
b.ul  re;.ponsil  ilitv  tor  .Kiminnte:  ing  .iiuf  eperatioy  th.’  J!  )S. 

J'  '!  'S  .illvi  Jib.,  luiV\  eV  ..'1 ,  couki  Out  Vi  !•  .  io.  el  V  lOiei  la.  .  vv|  1. 1  e.K  1 .  oti  lel  .inv!  vl  ;vi 

II.  it  perlorm  .ill  the  lunctioiT--  n -i  essar  .  lor  pla.n  devekq'inent  and  execolieo.  lu 

.  vi:  rei'l  till  -  vielk  i.'i  iv  V  ,  JV  'PS  aii-.i  |  DS  li.iv  c  I  '.-eo  u  pi.H'e.  i  bv  die  lodv.w-i  .a  JOl'IiS 

'V  sti'ia. 
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piaiiv  ,!i;d  ,,i  (j,(.  prep.uauou  i.l  .upi-eitiu:;  pl,.i.^.  Stand, .id  hi' s.  loiii-.its  .md 
I;  I  1 1.  .it ion  prri'.ounv  j-rov  ivi-.-  aippor'  n-r  l.u.  e  pl.iniiii  u;.  e,; ,i'.ur,it  -  u-!ai.  I  v  .i:  go 
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estimation,  logistic  Inctors,  civil  engineering  support,  and  medical  planning  " 
OOFS  Volume  III,  GM-524-S5,  p.  1-2.) 

JOPS  is  used  in  the  plan  development  phase  bv  the  Service  components  to  build 
the  force  li.-it,  calculate  the  flow  of  nonunit  cargo  and  personnel,  and  complete 
specialized  planning,  such  as  civil  engineering  and  medical  support.  An 
outcome  of  this  process  is  Ihe  TPFDD.  JOPS  can  oe  used  to  test  tlie  gross 
transportation  feasibility  of  the  TPFDD  and  to  revise  the  database  based  on  the 
deliberate  planning  refinement  conferences.  JOPS  provides  automated  aid  to 
strategi''  deploymer  "planning  and  limited  sustainment  planning,  but  provides 
no  aid  to  mcbility  ■  i  ployment  planning  other  than  establishing  ihe  force  list. 

In  this  sectic  n,  we  describe  the-  lOPS  database  files  and  application  orograms. 

We  then  describe  iiow  tf;i.s.’  are  used  ov  tne  JFEC  in  the  Plan  Development  phase 
of  deliberate  planning. 


Database  Files^ 

The  lOI’S  database  riles  are  maint  .mod  on  disk  and  use  the  Honeywell  6('00  ISP 
indexed  sequential  file  tructure  fe'rmat.  ANSI  COBOL  is  the  programming 
language  used  to  mainiain  these*  files.  Users  are  not  authorized  to  modily 
program  files  or  accompanyir.g  software  without  prior  approval  from  the  Office 
of  cnc  joint  Chiefs  of  Staff  Use  of  the  data  contained  in  Uie  file,  except  ns 
provided  for  by  the  JOPS  programs,  must  be  accomplished  through  command- 
unique  programs. 


a.  Figure  A.l  shows  jOPS  standard  reference  files. 

b.  JOPf-geiieratcd  plan-unu]ue  files  include  the  Time-i’l  asod  Force  and 
Deplovment  Data  iiie  iind  the  Summary  Reference  File  as  well  as  a  numhe,  c'f 
other  files  described  in  JOi’S  X’olume  III.  SM-524-85 


PFF  (MKGp 
PVVF: 

PFF  (LCE): 
FREE: 

POSF: 


PI  innij’g  Fatlofs  Ede  (MRC-) 
Personnel  VVurkiny;  Fi'e 
Piar.nmg  Fai  lu.  -.  File(LCE) 
Force  Record  Folract  Idle 
Ports  I’l  Support  Idle 


‘  1  his  sccii‘*n  Vi)?*  frojii 


(.  / ’''/NM.'Hv  \  .‘'urr.''  ii!  S'.'  K".  ||i  1  I 


Ih-lU 


67 


OPLAN.  The  OPL.AN  dependent  SRF  records  contain  all  Transportation 
Component  Command  (TCC)  generated  movement  tables. 

c.  Two  WVVMCCS  files  arc  accessed  by  jOPS: 

GEOFILE:  The  geographic  location  tile  contains  worldwide  geographic  data 
for  locations  specified  bv  different  commanders. 

SORTS;  The  status  of  resources  and  training  system  file  provides  general 
infc/rmation  for  units,  such  as  unit  name,  unit  type  code,  origin,  equipment 
and  personnel  readiness  data,  and  comniand  relationships. 

d.  JOPS  plan-generated  but  plan-independent  files  are  also  described  in  JOPS 
\'olume  Ill,  SM-524-85.  Tnese  arc: 

PDD:  Package  Designation  and  Description 
FPF:  Force  Package  File 
MEF:  Major  Equipment  File 
SDF:  Standard  Distance  File 

Applications:- 

System  Monitor:  This  control  program  allows  the  planner  to  interact  directly 
wiLh  the  FRG,  MRG,  NPG,  LCE,  MPM,  FMS  (Force  module  subsystem),  and  TFE 
in  a  conversational  mode  at  a  terminal  durmg  computer  operation.  It  permits  die 
planner  to  enter  and  change  parameters,  select  opuons,  and  specify  outputs. 

FRG:  Tlic  force  requirements  generator  allows  the  planner  to  select,  assist  in 
analyses  o.L  tailor  a  variety  of  force  options  for,  and  produce  a  time-phased 
deployment  scheme  that  will  support  the  mission. 

FMS:  The  fe.rce  module  subsystem  allows  JPEG  planners  to  link  the  force, 
nonuuii-ielated  cargo,  and  nonunit-related  personnel  information  logically 
within  a  JOPS  III  TPFDD  anU  SRF 

MRG:  The  movement  requirements  generator  generates  gross  nonunit-related 
cargo  transportation  requirements  tiased  on  the  forces  tube  supported  and  the 
i.iuration  of  ilie  |  'laniv  d  ijperalum  It  uses  factors  prt.\  ided  by  tiie  Sen  ice 
planner  in  developing  the  dails’  reipiiremi-iils  fiir  ri"-iipply  and  supple  huildup. 
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TFH:  The  transportation  feasibility  estimator  dctennines  tlie  gross  transportation 
feasibilitv  of  tlie  deployment  scheme  developed  in  support  of  the  operation  plan. 
It  consists  of  a  strategic  transportation  analysis  using  common-user  lift.  Tlic  TFE 
compares  movement  requirements  of  deploying  forces,  supplies,  equipment,  and 
replacements  with  available  sea  and  air  transportation  resources  and  considers 
specified  time-phased  reception  and  discharge  capabilities  of  the  deployment 
airfields  and  seaports. 

CE5PG:  The  civil  engineering  support  plan  generator  aids  the  jPEC  in 
devi'loping  and  evaluating  civil  engineering  support  for  OPLA\'> 

MPM:  The  medical  planning  module  provides  automated  assistance  to  the 
planner  in  quantifying  the  impact  of  an  -speration  on  an  existing  or  a  proposed 
medical  system 

N’PG:  Tlie  nonunit  personnel  generator  generates  gross  nonunit  personnel 
transportation  requirements  for  replacement  personnel  in  support  of  TPFDD 
forces  based  on  MPVl  projected  losses. 


77ic  Plan  Development  Phase  of  Deliberate  Planning 

The  mam  purpose  of  JOPS  is  to  assist  in  the  plan  development  phase  (Phase  Ill) 
of  deliberate  planning.  Using  JOPS  application  programs,  planners  create  a 
TPFDD  computer  file  by  entenii)!;  the  data  supjrlied  by  sources  throughout  the 
jPEC. 

There  are  eight  steps  in  the  plan  development  phase: 

•  Force  planning 

•  Support  planning 

•  Cheinical/nuclear  planning 

•  1  ransportation  pdanning 

•  Shortfall  identification 

•  Transpiortation  fea-ib:lit\  analv  sis 

•  I  I'l  DD  refinement 

•  Do^umi’iitation 

Step  1;  I  orce  Planning.  I  he  j'urposc  oi  tone  I'la'iiurig  is  to  idi'iU'ty  ..11  tones 
needed  to  ai.  i  omj'lish  tiie  C  I.\'l  's  c  oiuepl  ot  operation'-  and  j'h.ase  them  into  the 
tiieater  Force  [danning  is  ultimately  tlie  re^j  onsihililv  ot  tin-  suiqsutej 
I  ointnander,  hut  ino>l  ol  tlie  work  is  lione  t>\  tin'  Sit  ne  ;  iniponerits  l  ai  h 
SH'r  V  u  i'  (.  om  pollen  t  comniiiiide'  ile  veloj 's  hr-  o’.vn  tone  let  i  ompi  >'-ed  ot  corn  ha  t. 
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combat  support  (CS),  and  combat  ser\  ice  support  (CSS)  forces,  usmg  Service 
plannu'.g  documents  (the  Army  uses  the  four-volume  Army  Mobilization 
Operations  Planning  Systems,  or  AMOPS,  document).  AlUiough  the  apportioned 
major  combat  forces  may  have  been  described  m  relatively  large  fighting  units 
such  as  Anny  division  and  brigade,  the  final  product  for  each  Serv  ice 
component's  total  force  list  will  include  detail  down  to  the  unit  level  (e.g., 
battalions,  squadrons,  e^c.).  The  Services  have  Service-unique  s\  stems  for 
reportmg  detailed  unit  mformation  and  SeiTice-uniquc  systems  for  doing  their 
planning.  These  systems  may  be  hosted  on  a  V\'\VMCCS  node  and  interface  to 
JOPES  to  upload  and  download  planning  data. 

Deployment  planning  requires  the  development  of  movement  information  for 
each  unit  from  (1)  its  ongin  (ORG)  to  its  port  of  embarkation  (POE),  where 
strategic  air  or  sea  transportation  begins;  (2)  from  the  POE  to  the  port  of 
debarkation  (POD),  the  airport  o  seaport  withm  the  theater  of  operations  where 
strategic  transportation  is  tinished;  (3)  from  the  POD  to  its  destination  (DEST); 
and  (4)  for  intermediate  locations  (ILOC)  between  ORG  and  POE,  between  POE 
and  POD,  or  between  POD  and  DEST.  Since  the  timely  arrival  of  units  at  the 
DEST  is  the  key  to  successful  participation  in  the  ClNC's  movement  plan, 
planning  is  built  around  several  critical  times  that  include:  CLNC's  required  date 
(CRD);  the  times  of  the  earliest  and  latest  arrivals  of  tlic  elements  of  the  unit  at 
the  POD;  the  earliest  date  the  unit  is  available  at  the  origin  for  transport  to  the 
POE;  the  earliest  time  the  unit  can  begin  loading  at  tiie  POE;  the  earliest  date  the 
loading  can  be  completed  at  the  POE;  and  the  earliest  departure  date  froni  the 
POE. 

■A  force  list  can  be  built  in  several  ways.  The  planner  can  create  a  force  unit  by 
unit,  starting  with  the  apportioned  combat  forces  and  adding  all  necessarv  CS 
and  CSS  forces,  which  is  extremely  time-ci  nsummg.  An  alternative  method  uses 
force  modules,  which  are  groupings  of  combat,  CS,  and  CSS  forces  as  well  as  a 
calculated  amount  of  sustainment.  Force  n.odules  are  convenient  for 
manipulatmg,  identifymg,  and  monitoring  groupings  of  forces.  There  are  three- 
types  of  force  modules:  the  Service ,qomt  force  module  contains  combat,  CS,  and 
CSS  tvpe  units  with  their  associated  sustainment;  the  OPLA.NJ-dependent  force 
module  is  like  the  first  but  is  developed  b\  a  CIN'C  to  meet  specific  demands  of  a 
particular  OPLAN;  and  the  furce-tracl  mg  force  module  consists  of  major  combat 
units,  IS  OPl..AN'-independent,  and  does  not  contain  sustainment  data 

f\)rce  planning  usually  begins  with  using  the  characteristics  (e  g.,  personnel, 
categories  of  cargo,  weight  of  equipment  and  acrompanving  supplies,  etc.)  c'f 
notional  or  tvped  units  that  are  found  in  the  TUCHA  reierence  file  bv  unit  tvpe 
code  iUlC).  The  TL'CH.A  is  updated  quarterly  bv  the  Services.  .-X  TL'CH.A  unit 
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is  a  hypothetical  unit  withi  the  approximate  physical  and  movement 
characteristics  of  all  the  actual  (real-world)  units  it  represents. 

Each  separate  force  record  on  a  force  list  is  assigned  a  plan-unique  alphanumeric 
code  called  a  force  requirement  number  (FRN).  Charactenstic  blocks  of  FRNs  are 
identified  for  each  supported  commander,  and  each  OPLAN  uses  a  separate  FRN' 
to  identihy  each  unique  force  requirement.  When  an  FRN  ha;  been  assigned  to  a 
unit,  it  is  general  not  changed  in  the  course  of  a  plan.  It  is  useful  because  it 
allows  the  plamer  to  track  a  unit  that  may  have  changed  sequence  in  tlie  TPFDD. 
Two  additional  characters,  called  fragmentation  and  msert  codes,  may  be  added 
to  the  FRN  to  ider.tih'  a  force  entry  that  requires  more  than  one  iteration  of  the 
FRN  to  satisfy  the  force  requirement,  such  as  three  indn  idual  bngades  to  satisfy 
die  requirement  for  a  division.  This  resultmg  identifier  becomes  the  unit  Ime 
number  (L'EN). 

The  JOPS  Force  Requirements  Generator  (FRG)  application  is  used  to  help  the 
planner  m  creating  a  force  requirements  file,  analyzing  tfie  data,  and  changing 
the  data.  It  consists  of  a  series  of  modules  that  (1)  aid  the  planner  with  cieiical 
tasks  such  as  selectmg,  deleting,  or  modifying  type  units  nr  force  modules  and 
modifying  the  information-defining  movements,  (2)  split  the  movement  of  a 
force  record  into  air  and  sea  shipment;  (3)  assign  unit  parameters  to  mdividual 
units  or  groups  of  force  records;  (4)  reorder  the  list  of  movements  based  on 
planner-selected  criteria;  (5)  selectively  create  summaries  of  transportation 
requirements,  (6)  identify  for  analysis  a  categorized  list  of  support  forces;  and  (7) 
lay  the  groundwork  for  analyzing  gross  transportation  feasibility  of  force 
records.  The  FRG  uses  most  of  the  JOI^S  reference  files  desenbed  earlier. 

The  Force  Module  Subsystem  (FMS)  allows  the  planner  access  to  the  Force 
Moauie  Library,  which  contains  previously  defined  force  modules — complete 
combat  packages  made  up  of  comuat,  GS,  and  CSS  forces  in  addition  to  some 
nonunit  cargo  and  personnel.  The  F.MS  allows  the  planner  to  build  a  new 
TPFDD,  modify  an  existmg  TPFDD;  go  into  an  existing  1 PFDD  and  group  force 
entries  into  a  new  or  existing  force  module;  define  new  force  miadules,  modify 
and  delete  existing  modules;  and  audit  die  tile's  Cargo  Increment  Number  ((TIN) 
for  iionunit  caigo.  Personnel  Increment  Number  (Pl.N)  for  nonunit  personnel, 
and  ULN.  It  also  allows  large  groupings  i)f  force  entries  to  be  identified  tor  ease 
in  monitoring  during  plan  execution. 

.'\  component  planner  uses  the  FRG  and  its  standard  reference  files  to  create  a 
total  component  force  list.  Given  the  mission,  the  planner  reviews  the  t\  pe  ot 
combat  forces  apportioned  in  the  task-assigning  divument  and  determines 
appl. cable  CS  and  CSS  units  from  the  Service  plannmg  documents.  Tlie  plan  is 
built  by  selecting  individual  units  bv  L’nit  Type  Code  (U  IC)  oi  an  entire  torce  as 
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an  FM.  When  UTCs  are  entered  individually  or  collectively  as  a  force  module 
into  the  TPFDD,  the  FRG  automatically  copies  the  unit's  description  and  its 
movement  characteristics  data  from  theTUCHA  and  adds  them  to  the  working 
TPFDD, 

The  collection  of  the  components'  force  lists  is  merged  bv  tire  ClNC's  staff  and 
becomes  the  ClNC's  consolidated  force  list.  The  database  is  called  the  OPLAN' 
TPFDD.  When  the  supported  commander  concurs  with  the  consolidated  force 
list,  the  components  then  add  any  missing  information  needed  to  deploy  their 
Services'  forces  from  origm  to  destination,  such  as  mode  and  source  of 
transportation,  POD,  priorih,’  off-load  at  POD,  etc. 

Step  2:  Support  Planning.  The  purpose  of  support  plannmg  is  to  identify  the 
quantities  of  supplies,  equipment,  and  replacement  personnel  as  well  as  civil 
engmeering,  medical,  and  POW  materials  required  to  sustam  the  forces 
identified  m  force  plannmg.  During  the  support  planning  step,  planners  are 
primarily  concerned  with  how  much  strategic  lift  will  be  needed  to  move  the 
support  requirements,  but  before  the  OPL.AN'  is  complete,  requirements  will  be 
defined  in  more  detail.  Suppoit  plannmg  is  completed  when  all  significant 
support  requirements  have  been  determined,  consolidated  by  the  supported 
commander,  and  then  entered  into  the  Tl’FDD  file. 

The  actual  support  calculation  uses  consumption  rates  developed  and 
maintamed  by  the  Services  under  their  responsibility  to  supply,  equip,  and 
mamtaln  their  forces  assigned  to  combatant  commanders.  This  calculation  is 
generally  made  by  the  Service  component  commanders,  who  refer  to  Service 
plannmg  guidelmes  and  Service  doctrme,  but  it  is  aiso  possible  for  the  supported 
commander  to  perform  the  calculations  using,  component-supplied  force  lists  and 
Seivicc  plarmmg  factors. 

Support  IS  computed  for  unit-related  supplies  and  equipment  including  a  unit's 
organic  equipment,  basic  load  or  quantities  required  to  be  on  hand  within  a  unit, 
and  additional  accom.panymg  supplies  specified  by  the  CINC.  These  are 
identified  in  the  TI’FDD  with  the  unit.  Nonunit-relaled  supplies  and  equipment 
include  all  support  requirements  not  m  the  TUCHA  or  augmented  bv 
accompanying  supplies.  Categories  include  pre-positioned  war  reserve  materiel 
stocks,  sustaining  supplies,  resupply,  supply  buildup,  and  replacement 
personnel. 

Tire  Mnvemi'nt  Kequiiements  Generator  (.MRG)  is  the  JOI’S  applicatK'n  program 
used  support  planning.  It  calculates  the  gross  non-unit-related  equ’pment  and 
sup  '>  support  the  (DPL.AN.  Tliese  calculations  dctennme  the  nonunit 

nui\  .  requirements  b>  using  numbers  i>t  personnel,  number  <ind  types  of 
LdCs,  oervice  planning  factors,  and  user-supplied  Cl.NiC  [Planning  guidance. 
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Those  gross  determinations  for  supplies  arc  translated  into  weights  and  volumes 
and  added  to  the  TPFDD. 

The  MRG  allows  the  plarmcr  to  use  data  from  a  reference  file  to  create  an 
OPLAN-depondent  ports  of  support  file  (POSF)  categorized  bv  Service,  supplv 
destination,  a:r  and  sea  transport,  and  ammunition  and  POL.  It  also  allows  the 
planner  to  use  data  from  a  reference  file  to  create  planning  factor  files  (PFF)  and 
UTC  consumption  factor  files  (UCFF)  based  on  Service-developed  logistics 
factors,  and  to  calculate  the  nonunit  movement  requirements.  The  planner  can 
selectively  aggregate  the  data  to  reduce  the  number  ot  nonunit  cargo  records 
using  the  earliest  to  latest  date  of  arrival  window  at  each  port  of  support  and, 
thus,  can  better  pattern  the  movement  requirement  for  containerized  cargos. 

The  Civil  Engineering  Support  Plan  Generator  (CESPG)  application  is  used  to 
analyze  engmeermg  requirements  of  planned  contingency  operations.  Tliese 
mclude  facility  asset  data,  anticipation  of  new  facilih  requirements,  projection  of 
war  damage,  recognition  of  actual  and  projected  cn  il  engineering  forces, 
detemunation  of  required  civil  engineering  materials,  and  acknowledgment  of 
available  support  from  the  host  nation.  The  CESPG  allows  the  planner  to 
maintain  unit  and  facility  information  in  existing  files;  analyze  troop  and  facilih' 
requirements  from  the  TPFDD;  determine  facility  requirements  based  c-n  forces 
employed,  unit  mission,  and  war  damage;  schedule  existing  engineering 
manpower;  and  prepare  reports  to  identify  facility  and  construction 
requirements  and  develop  scheduling  intormatic 

The  Medical  Plannmg  Module  (MPM)  is  a  menu-driven  subsystem  that  predicts 
and  evaluates  medical  requirements  in  support  of  the  OPLAN.  The  process 
considers  the  population  at  risk,  length  of  stay  in  the  hospital  facilities,  and 
Service-developed  frequency  data  for  uijurc'  and  death.  The  result  is  a  plannmg 
tool  to  determine  patient  load,  requirements  for  patient  evacuations,  and  botli 
Service  and  component  medical  planning  requirements.  Tlie  products  of  the 
MPM  are  used  as  medical  annexes  to  the  OPLAN  documentation,  mput  to  MRG, 
input  to  tile  Nonunit  Personnel  Generator  (NPG),  input  to  sustamment  planning 
modules,  identification  of  possible  medical  deficiencies  Ui  the  OPLAN,  and 
analysis  of  the  impact  of  CO.As  on  medical  requirements. 

Tlie  NPG  application  program  offers  an  automated  capabiliti  to  generate  TI'’FDD 
records  for  tlie  m.ovement  of  nonun  t  replacement  per>onnel 

Tlie  Logistics  Sustainability  Analvsis  Feasibilitv  Estimator  (LtK'iSAld-.i  is  under 
development  to  replace  the  MRG  and  Logistics  Capabilit\-  Estimator  (LCE).  it 
will  pertorni  essential  sustainment  item  modeling  and  general  supply  modeling 


step  3:  Nuclear/Biological/Chemical  <NBC)  Planning.  The  componont 
commands  submit  their  chemical  warfare  requirements  to  tiie  supported 
command.  Service  component  commanders'  plans  for  operation  m  a  chemical 
environment  are  consolidated  into  a  smgle  jomt  stand-alone  TPFDD  file,  separate 
from  the  OPL.^N  TPFDD. 

Nuclear  plannmg  for  strategic  retaliator\'  strikes  in  general  war  is  conducted  by 
the  Joint  Strategic  Target  Planning  Staff  (JSTPS)  at  Offutt  AFB,  Nebraska,  in 
coordination  with  U.S.  unified  and  specified  combatant  commander.'^  and  certain 
allied  commanders.  The  product  of  this  planning  is  tlie  Smgle  Integrated 
Operational  Plan  (SlOP).  JSTPS  plannmg  does  not  use  JOPS. 

Step  4;  Transportation  Planning.  Transportation  planning  is  done  by  the 
supported  commander.  Tlie  task  is  to  simulate  the  strategic  moven  ents 
generated  by  component  planners  durmg  the  force  plannmg  and  support 
planning  steps  usmg  the  apportioned  strategic  transportation  resources.  The 
goal  in  transportation  plannmg  is  to  produce  a  feasible  strategic  transportation 
movement  m  support  of  the  CINC's  plan,  a  ver\’  difficult  thmg  to  do.  It  is  an 
iterative  process — if  the  simulation  indicates  that  the  forces  and  nonunit  supplies 
cannot  be  moved  in  time,  planners  identify  the  problems,  evaluate  their  impact 
on  the  overall  plan,  incorporate  solutions,  and,  if  necessary,  simulate  the  strategic 
move  agam. 

The  first  step  of  iterative  transportation  planning  is  to  complete  the  fome  and 
nonunit  record  entries  and  to  enter  all  available  information  in  the  TFFDD.  The 
next  step  is  for  the  component  planners  to  designate  as  many  actual  units  as  they 
can  to  replace  the  type  of  upits  in  the  force  list.  Ihis  is  known  as  sourcing.  In  the 
,‘\rmy,  sourcing  begins  m  tlie  force  selection  by  FORSCOM.  Real-world  units  are 
sourced  in  the  force  list  by  matching  each  ULN  with  a  unit  identification  code 
(UIC)  that  uniquely  identifies  each  active.  Reserve,  and  National  Guard  unit  of 
the  Amied  Forces. 

The  Transportation  Feasibility  Estunator  (TFh)  application  is  used  to  simulate 
strategic  movement.  TFE  is  made  up  of  four  phases: 

•  Tlie  TPFDD  evaluation  phase  allows  the  planner  to  display  and  analyze  the 
mformation  already  in  the  TPFDD 

•  The  simulation  preparation  phase  sets  the  planning  parameters  tT'r  running 
the  simulation.  In  this  phase,  tlie  movement  infomiahon  is  extracteil  from 
the  TPFDD,  distance  data  are  generated  from  reference  file  ,  port  constraints 
are  identified,  straiegic  transportation  assets  are  selected  to  match  the 
apportioned  forces  Irom  the  JSt'P  or  iask-.is:-.ignipg  document,  the  asset 
characteristics  are  defmed,  and  the  attrition  rates  are  introduvcd. 
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•  In  simulation  oxocution,  the  transportation  flow  is  modeled  based  on  the 
identified  parameters;  the  results  are  displayed  in  cither  summary  or 
detailed  form. 

•  Post-simulation  prixessing  produces  reports  that  idcntifi’  the  computed 
estimated  departure  date  from  the  POE  and  feasible  arrival  date  at  the  POD 
Modules  in  this  phase  display  information  requested  by  the  planner  to 
analyze  the  movements,  such  as  an  exception  report  of  unmatched  records 
that  did  not  close  (i.e,,  a  shortfall  is  said  to  exist  when  it  is  determined  that 
the  expected  arrival  of  forces  and  supplies  at  the  DEST  does  not  coniorm  to 
CIN'C  requirements). 

The  requirement  to  transport  personnel  and  materiel  from  the  theater  of 
c>perations  requires  close  coordination.  Tlie  movement  of  equipment  requiring 
repair,  noncombatant  e\  acuation  operations  (KEO),  and  medical  evacuatior.  out 
ot  the  combat  theater  are  also  concerns  of  the  logistics  planner.  Recent 
experience  with  computer  simulations  has  demonstrated  this  is  more  of  a 
problem  than  originallc  thought.  To  consolidate  diese  operations,  a  separate 
retrograde  TPFDD  is  created.  The  Medical  Evacuation  System  (MEDEVAC)  is 
the  applicaticin  that  fcxusesva'i  thie  iiio^etneiil  of  inedicaiiN'  ewicudteQ  per.sciimei 
and  c,.igo  from  the  theater.  The  MPM  generates  the  number  of  c.  acuees,  and  the 
data  are  leceived  from  MPM's  medical  working  file.  Tlie  product  of  McDEV.AC 
IS  added  to  the  OPLAN  Tl’FDD. 

Step  5:  Shortfall  Identification.  Shortfalls  are  identified  and  resolved 
throughout  the  planning  proce.ss.  This  step  fixuses  on  identifs  ing  and  resoK  mg 
transportation  shortfalls  highlighted  the  TFE  deployment  .simulation.  The 
TFE  not  cnlv  identities  the  late  arrival  shortfalls  but  also  identifies  the  reasons  for 
them  such  as  shortage  of  lift  resources,  overkiadcd  niobilitv  support  tacilitie;-, 
excessn  e  requirements  for  intratheafer  lilt,  etc 

rianners  identit\'  unresolved  shortfaF'  -  loi  corn-  've  a^tums  bv  higher-level 
decisionmakers,  or  those  that  mu>t  be  resnKx-d  we  n  other  commanders  h  v 
compromise  or  mutual  agreemen..  Ihe  i  T:\c  ai.  ine  apj'roves  changes  tliat  alteci 
tiie  concept  or  operations  or  the  concept  of  sur  port 

If  shortfalls  are  not  resolv  ed,  the  OI’L.AN  ! ,  submitted  based  on  capabilities,  and 
the  Plan  hummarv  will  assess  the  impact  ot  the  ''hortfalls  and  limiting  factors  and 
list  the  tasks  tiiat  cat. not  be  accomplished  .A  separate  Tl’FDD  is  submitted 
identifying  the  shortfall  force  and  nonumi  cargo  record,-^:  tlieM'  shorttall.s  are 
considered  uiisourced  rather  than  |ust  kite  closures. 

Step  6:  Transportation  Feasibility  Analysis.  Formal  analysis  oi  strategic 
transportation  occurs  in  this  step  d  lu'  tools  have  been  identified — a  evi;iiputer 


simulation  and,  if  nccessan',  a  plan  development  conference  of  ke\'  players  will 
be  held  to  resolve  the  shortfalls  or  to  assess  their  impact  on  the  OPLAN.  After 
the  computer  simulation  and,  possibly,  several  iterations  of  the  transportation 
steps,  the  product  is  the  conclusion  by  the  CINC  tliat  tJie  OPLAN  is  grosslv 
transportation  feasible. 

Step  7:  TPFDD  Refinement.  The  plan  development  phase  consists  of  se\  oral 
subphases:  forces,  logishcs,  and  transportation,  with  shortfall  identification 
associated  with  each  phase.  The  plan  development  pihases  are  collectn.  cK 
referred  to  as  TPFDD  refinement. 

Step  8;  Plan  Documentation.  The  objective  of  this  phase  is  to  document  the 
operation  plan  m  JOPS  format  for  submission  and  distributicm.  The  fulK 
documented  plan,  includmg  the  refmed  TPFDD.  is  an  operation  plan  ua  complete 
format  (OPL.-\.\’). 

The  JDS  System^ 

JDS  is  a  transaction-orieiited,  distnbuted  database  system  that  allows  tlie  u.ser  to 
update  tJie  local  database,  which  then  may  be  transmitted  to  oilier  sites  over  the 
WIN.  It  is  a  system  of  people,  procedures,  communications  capabilities,  and 
.‘\DP  equipment  that  manages  the  timely  flow'  of  deployment  data  within  the 
JPEC.  The  JDS  IS  part  of  WWMCCS  and  interfaces  with  other  conuiiand  and 
control  systems. 

In  this  section  we  discuss  JDS  capabilities,  the  JDS  integrated  database  system, 
and  the  JDS  application  programs. 

Capabilities 

JDS  can: 

•  simultaneously  build,  maintain,  and  manage  exerci.se  and  real-world 
deployment  plans; 

•  establish  OPLANs  or  COAs  trom  JOPS-created  depkwment  plans  or  force 
modules; 

•  create  a  JOPS-fomiatted  deployment  plan  from  the  JDS  database, 

•  add,  change,  or  ilelete  infomiation  bv  using  computer  terminals  or 
automated  system  interfaces; 
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•  schedule  or  monitor  deployments, 

•  offer  close-hold  capabilities  to  develop  OPLANs;  and 

•  manage  deployment  information  to:  automatically  alert  units  and 
installations  of  scheduled  deployments  via  AL'TODINJ;  monitor  ongoing 
s\  stem  performance;  integrate  force  module  capabilities;  and  impro\  e  the 
timeliness  and  accuracy  of  deployment  information. 

Integrated  Database 

The  JDS  is  built  around  a  centralized  integrated  deployment  database  established 
and  maintained  on  tfie  USTR.4NSCOM  VVVVMCCS  computer  at  Scott  Air  Force 
Base,  lllmois.  Several  sites  duplicate  the  database  and  can  serve  as  backup  if  it 
should  become  inoperative.  The  JDS  database  is  resident  on  the  Honeywell  IDS  1 
database  svstem.  It  is  tlie  primarv  repository  of  deployment-related  infonnatu'n 
and  contauts: 

•  narrative  information  on  plan  concept,  scope  and  status; 

•  liiiie-plidseu  force  and  sustainment  requirements  that  are  either  available 
from  an  existing  plan,  built  line-by-line  with  force  and  cargo  records,  built 
witli  force  modules,  or  created  by  a  combination  of  these  methods; 

•  hypothetical  (notional)  data  that  may  be  refmed  and  updated;  actual  unit 
data  that  are  sourced;  and  individual  entries  of  CI\',  PIN,  and  ULN  data  that 
may  be  updated  and  refined  to  improve  visibility  as  the  situation  changes, 
and 

•  movements  requirements  that  are  visible  and  accessible  for  preparing  the 
transportation  schedule  and  building  the  manifest 

System  Operation 

Interactive  user  entries  geneiate  tiansactiuns  liiat  update  the  local  database  and 
may  then  be  transmitted  over  tlie  WIN  to  update  the  central  deployment 
database  at  USTR/XNSCOM  and,  nearly  instantaneously,  all  oilier  affected  sites 
in  the  IPEC. 

JDS  supports  the  planner's  functional  requirements  with  the  following 
application  subsystems; 

•  filan  infoimation:  displays  and  updates  narratii'e  plan  information; 

•  requirements:  enters,  stores,  updates,  and  retrieves  force  and  sustauiment 
mfumiation; 


•  unit  information:  rctnc\'es  and  updates  selected  unit  data; 

•  force  module:  using  Sereice/Joint  or  OPLAN’-dependent  force  modules, 
rapidly  builds  and  tailors  requirements  m  support  of  OI’L.AN  or  COA, 

•  schedule  and  mo\'ement:  reviews  and  updates  schedules,  and  manifests 
movement  inionnation  during  planning  and  execution; 

•  retrieval;  retrie\'es  and  reviews  database  information; 

•  information  resource  manager:  performs  local  database  management 
functions; 

•  automated  scheduling  message:  generates  ALiTODlX'-format  messages  from 
jredata. 

TOPES 

JOPES  is  the  new,  e\  oK  ing  svster.i  for  performing  joint  planning  that  coir  I'lnes 
both  peacetime  and  wartime  planning  Tlus  section  discusses  JOPES'  tn  erail 
system  goals,  organizational  responsibility  for  JOPES,  oiid  iuture  plans. 

Goals 

JOPES  is  the  joint  command  and  control  system  for  conventional  operation 
plannuig  and  execution  and  is  intended  to  address  mobilization,  depkn  meat, 
employment,  and  sustainment  mission  areas.  It  is  designed  to  supf  ort 
commanders  and  planners  at  national, eater,  and  suppiirting  levels. 

The  primary  goals  of  JOPES  arc  to: 

!  Support  the  development  of  OPLA.Njs  within  4?  da\  s  of  concept  a'^proc  al 
and  the  development  of  an  OJ’OKD  within  tiuee  davs  after  XCA  COA 
selection  in  a  no-plan  situation. 

2  Peniiit  tiieater  commanders  to  start,  stop,  or  reriirect  nul.tari'  operations 
effect’ vely  and  rapidly 

.3.  Support  pi’acetirnc,  crisis,  and  waitime  planning  and  exerutu'n. 

4  Integrate  mobilization,  deplo\  menl,  I’lnphn  nient,  and  suslainnu  nt  actmties 

3.  Standardize  policies  and  procedures  which  will  be  similar,  il  not  identical,  in 
peacetime  (including  exercises)  and  crisis  situation.s. 

''’1  ]\v  ri’sl  ol  this  sfct !on  up  \o  t. )r^.iP'U7,.Hior  lU’sponsjhililii’N  h.js  Irpu  taM  o  ni.iink  I  rcir  t.'if  /i 

<  fh  b’  /  n  i  J  !  ‘'I'Pvjar',  o  |'<ko  |[  .. 

thi’  rolativj'lv  timi  plnn^  {nr  tha'.  vvrrc  ottic;.’!  up  until  Iho  sununcr  t'f  l''■C  'a  hen  rio'st 
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6.  Sup^pi'rt  tile  rapid  dc\  clopmcnt  and  evaluation  ot  iiulitarv  options  and  CCl.As 
in  single  or  multitheater  scenarios. 

7.  Fixploit  ADF  and  comnrunication  advances  being  made  in  the  VVWKICCS 
Infonnation  S\  stem  ^VVIN)  and  Deiense  D.ita  Ketwoik  iDDN) 

8.  Exjiedite  the  development  o!  niilitarv  estimates  ot  a  situation. 

9.  Ensure  tlie  dissemination  and  presentation  ol  timely,  accurate,  and  pmperK' 
aggregated  infoi-mation. 

10.  Allow  planners  to  identiiA  resnurce  .'•hoitialls  (personnel,  transport. lii'an, 
materiel,  iorces,  medical,  and  ci\  il  enguieenng  sein  ices) 

1 1.  Secure  the  svstern  tiom  unauthorized  access,  data  manipulation,  or  i-i,!!,! 
retrie'.'.il.  Svstern  hardu  are  nnwt  be  TEMFEST-qualilied  (or  placed  in  a 
secure  control  zone)  an.l  must  be  security-certifiable  for  TOE  SECIREI 
sensito’e  cumpartnie.ued  intormation  (SCI). 

JOEES  embodies  a  single  sv't  iif  |oint  pri'cedures  that  addresses  all  classic 
functional  aspects  c'l  joint  coaventu'iial  planning  and  execution  during  [leace, 
crisis,  war,  or  exorcises.  Ereviouslv,  )omt  planners  were  reciuired  to  be  proiicient 
in  procedures  of  several  systems  tlrat  were  limited  in  scope  and  Ic'Cused  on 
deployment. 

]C)EES  procedures  are  supported  by  an  integrated  .AIS  support  structure. 
Erevioiisly,  planners  were  roc^uired  to  be  proficient  on  multiple  systems. 
Communication  among  elements  of  the  JEEC  was  difficult  due  to  the 
incompatibilitc’  of  the  different  .'\l8s.  Ifata  comniunicatii''n  was  hampered 
because  systems  did  not  have  the  capability  to  efficiently  pass  data  because  of  the 
lack  of  standardized  data  elements.  Complex  algr'rithins  had  to  l.’e  developed 
bofeme  data  could  be  readilv  exchanged  between  systems  The  JOEES  lo ulution 
begins  by  integrating,  jOES  and  |I.)S  oapahilifies  and  deycToping  the  WTSIdlM 
(Wart. ire  and  Intelligence  System  I3ictic>naiy  for  Intormation  Management)  as  the 
central  repository  lor  all  stanvlardized  data  elements  for  the  JEEC. 

JOEES  I'rocedii’-es  pro\  idc  a  guide  lor  the  jl’EC  to  lollow  in  I'xecuting  the  JclELS 
act I'.  itu's  cif  mobilization,  depliiyment.  empkn  ment,  and  susl.iinment.  l  ln-  lesult 
IS  a  set  iit  executable  )oint  OELANIs  and  C.TI’OROs 

TTu’  JOITS  C\>i\cepl  i.'i  C'pi'i'.ttioiv-  ii.  s>  nl'c  ■  It^EES  c.s  a  set  vl  si.'\  en  inter  icia!e..l 
pio^esses  tluit  support  decisionmaking,  pl.inning,  and  execution  These 
processes  aii'  threat  id‘’ntilicatu>ii  aiui  assessuu-nt..  stret,.^',-  detemimatioti,  course 
of  action  de'.  elopmenl,  execution  planning,  iinplemenlation.  moniturmg,  .iiul 
siioulafion  and  anaU  sis  Nh  'iiiionm;  aiui  simulation  and  aii.iK  sis  prin  uii 
continuous  suppoi  (  to  ilu-  other  five  lupctionai  pro.  esses. 
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Organizational  Responsibilities 

Figure  A. 2  shows  the  organisations  that  were  responsible  for  JOPES  during  the 
ODS  period  and  their  relationships  to  each  other.  JS/J7  is  the  otfice  of  primarv 
responsibility  tor  the  JOPES  process  and  procedures  as  well  as  the  JOPES  AIS 
R&D  program  and  O&M.  The  WWMCCS  ADP  Mcdemisation  (VVAM)  office 
allocates  JOPES  R&D  funds. 

Ih?  JOPES  Project  Group  co-located  with  L'STR.‘\N'SCOM,  reports  to  J7 

and  IS  responsible  for  developing  the  future  requirements  of  JOPES  in  accord 
with  the  JOPES  ROC  (required  operational  capacity),  coordinating  working 
groups,  overseeing  the  development  and  testmg  of  research  prototy  pes,  setting 
priorities  and  schedules,  and  defining  the  version  plans. 

Tne  JOPES  ROC  contains  JOPES  support  elements  (_JSEs)  v\-ith  bedrock 
milestones  and  functional  requirements.  The  JPG  supports  prototyping  to  help 
define  requirements  (e.g.,  23  prototypes)  and  recommends  priorities  and  dollars. 
JPG  has  three  basic  ways  of  fulfilling  the  JSEs:  they  update  existing  JOPES 
applications  to  satisfy  a  JSE;  they  adapt  and  incorporate  other  systems  to  satisfy 
the  JSE;  and  they  develop  (or  contract  for  the  development  of)  prototypes. 

Tlic  JPG  coordinates  JOPES  Project  Working  Groups  in  functional  areas 
established  in  the  JOPES  Terms  of  Reference.  These  look  at  tlie  functional  needs 
of  users  and  then  attempt  to  define  and  refine  JOPES  requirements. 

The  Defense  Information  Systems  Agency  (DISA)  and  its  Defense  Systems 
Service  Organization  (DSSO)  have  two  major  JOPES  responsibilities;  they 
develop  JOPES  versions  under  the  WAM  program  in  response  to  J7  through  JPG 


Figure  A. 2 — JOPFS  Development  Organization 


so 


and  JOFES  O&M  in  response  to  Jd.  Because  ol'  the  enaphasis  on  deployinent  in 
the  early  JOPES  versions,  L’STRAN'SCOM  was  to  play  a  major  role  in  JOPES 
R&D  through  Version  5.  US  TR-AiN’SCOM's  responsibilities  included  R&D  for 
lOPES  through  Version  5.  O&M  support  for  JIDS  through  P'i'OZ  (support  from  the 
Air  Force),  and  responsibility  for  JOPES  training  (support  from  the  four  ser\  ices). 

The  JOPES  Terms  of  Reference  lay  out  the  reiationsh.ips  between  the  different 
groups.  The  DSSO  has  been  responsible  for  supporting  JOPS  and  the  JOPS 
subsystem  of  JOPES  USTI^ANISCOVl  has  been  responsible  for  JDS,  wh  ;h  is  the 
second  major  subsystem  of  JOPES.  (Since  ODS  was  a  crisis-planning  situation, 
the  major  JOPES  player  was  US'PIT'XMSCOM.) 

h'uturc  Plans 

JOPES,  as  an  evolying  system,  was  scheduled  tea  be  fielcfed  in  discrete 
developmental  steps  called  irrsums-  The  first  four  versions,  as  an  aggregate,  were 
designed  to  provide  a  quantum  improvement  in  the  supporting  software  for  the 
JPEG.  Figure  A. 3  summarizes  the  JOPES  development  strategy  for  versions  1 
through  4. 
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Version  1  was  fielded  in  Noveinhcr  1989  and  demonstrated  the  JOPES  Initial 
Operatmg  CapabilUy  (IOC).  It  provided  enhanced  capability  on  the  current 
hardware  suite  m  the  following  ways;  (1)  it  allowed  the  user  to  log-on  to  a  single 
svstem  with  menu  selection  to  all  )OPS  arid  JDS  subsystems  and  to  move 
between  applications  without  logging  off;  (2)  it  allowed  the  user  to  assess  a  plan 
for  logistic  and  transportation  feasibility  whether  the  plan  was  built  using  JDS  or 
JOPS  subsvstems,  and  (3)  a  JDS/IOPS  data  interface  enabled  a  selective  batch 
routine  to  reformat  data  in  on-lme  JDS  format  to  JOPS  TPFDD.-'SRF  (summary 
reference  file)  format  for  immediate  use  in  the  TTE,  MP.Vl,  MPG,  and  MRC 
subsystems. 

Version  2,  installed  m  April  1990,  w’as  operational  at  the  onset  of  OD5.  It 
pioviued  enhanctJ  capability  on  the  current  hardware  suite  by;  (1 )  expanding 
the  JDS/JOPS  data  interface  by  allowing  direct  input  to  the  on-line  JDS  database 
from  JOPS,  MRG,  NPG,  and  MPM  (MEDEVAC);  (2)  prox  idmg  the  first 
opportunity  for  functional  prototvpes;  (3)  expanding  the  navigation  capabilities 
from  JOrS  subsystems;  and  (-i)  offering  an  ad  hoc  query  capability  through  the 
Joint  Operations  Graphics  System  JOGS). 

Version  3  was  installed  in  December  1990  and  provided  enhanced  capability  on 
the  current  hardware  suite  mainly  in  the  graphics  area  wi‘h  the  use  of  Harvard 
Graphics,  a  commercial  off-the-shelf  pioduct.  It  also  added  the  following 
features  developed  during  ODS:  (1)  baseline  installation  of  an  interface  from 
MAC'S  GDSS  to  JOPES;  (2)  a  fix  to  allow  users  to  recover  lost  TPFDD  records  by 
rctrievmg  the  records  from  the  database  transaction  log;  and  (3)  capability  to 
generate  a  report  on  database  updates. 

Version  3.1  was  installed  in  May  1991.  It  provided  enhanced  graphics  and 
allowed  user-defined  ranges  for  dates. 

Version  4,  which  was  scheduled  to  be  released  in  1992,  would  have  provided  the 
JOPES  New  Plan  Build  option  to  sites  having  WAM  workstations.  In  addition  tti 
the  features  shown  in  Figure  A. 3,  the  software  was  to  include:  rcengineereci 
JOPS  and  JDS  components,  integrated  ad  hoc  data  retrieval  md  presentation 
(tabular  and  graphic),  retention  of  JDS  interfaces  and  addition  of  JMAS  (Joint 
Mission  .'\pplic;ilion  Software)  interfaces,  new  data  network  distribution 
software,  new'  database  update  software,  improved  data  integrity  capabilities, 
and  GLOI'lLE,  I’OR  IS  and  APOKIS  data  files  inli'grated  intii  a  relational 
database  on  the  w  orkstation 

Because  of  problems  with  the  Honey-Mac  workstation,  however,  much  of  the 
development  effort  for  Version  4  was  moved  to  a  Sun  workstation  m  November 
i"o()  I't,,.  'V  am  off;,;c  hoped  to  Continue  piototvping  on  Uie  Sun  and  then  port 
till’  iinpiementation  to  the  Honev-.Mac  workst,  tion  so  that  the  I  lonev-Mac  could 
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remain  the  approved  workstation  in  the  field,  since  many  sites  had  alreadv 
m\’ested  m  the  equipment.  Continuing  frustration  with  Version  4,  however, 
eventually  caused  its  suspension  and  the  suspension  of  most  other  JOPE5 
developments. 

At  that  time  the  Air  Force  was  directed  to  integrate  several  of  the  more  needed 
(and  more  ready)  capabilities,  such  as  a  new  scheduling  and  movement 
subsystem  that  allows  tracking  of  actual,  as  well  as  planned,  shipments  into  the 
existing  Version  3.  The  general  future  of  VV.4M  and  JOPES  is  currently  very 
uncertain. 

The  JOPES  AIS^ 

Overview.  JOPES  .41S  is  a  planning  and  execution  system  that  provides  for  a 
timely  How  of  deployment  data  throughout  the  JPEC.  The  mam  portions  of  the 
svstem  are  provided  by  JDS  and  JOPS  subsystems,  JOPS  standard  reference  files, 
and  an  evolving  integration  package  that  consolidates  and  improves  existing 
software.  JOPES  is  hosted  by  WTVMCCS  and  mtertaces  with  other  .'\JSs.  JOPES 
applications  are  run  against  an  on-line  database  that  can  be  distributed  either 
locally  or  worldwide.  ViabiUty  of  the  database  depends  upon:  (1 )  TPFDD 
development  and  maintenance,  (2)  timely  and  accurate  information  update 
during  deplo\Tnent  planning  and  execution,  and  (3)  standard  JPEC  procedures  to 
ensure  interoperabilitv’  between  peacetime  and  crises  environments. 

The  Version  3  JOPES  interface  provides  support  for  debberate  and  crisis-action 
plannmg  through  a  two-way  interface  between  JOre  and  JDS  th.at  allows  direct 
mput  to  the  on-lme  JDS  database  from  most  JOPS  applications  (except  for  the 
Force  Requirements  Module  and  the  Force  Module  Subsystem). 

VWVMCCS  Host  and  Communications  Network.  JOPES  resides  on  the  standard 
■MS  equipment  for  \V\VMCCS,  a  Honeywell  biformation  Systems  (HiS)  Senes 
6000  or  8000  computer  system.  Tenr.mal  support  is  provided  by  Honeywell 
Vi.sual  Information  Projection  (VIP)  tcrmmals  or  personal  computers  (c.g., 
WISCUC,  IBM  AT,  Zenith  248,  etc.)  modified  for  forms  mode  operation. 
Graphics-capable  terminals  provide  additional  terminal  support.  A  new 
gcneraiic."'.  Hc.npywell-. Apple  PC  will  also  be  available  as  the  first  of  a  new  family 
of  work-stations. 


IS  n«3 rt  i/(  Ml*  rerv'''t  m.iinU-  Or»r» p’,  rs 7n'i  tcp slc‘  .'f.'*; 

I  li  )ht^!  C>cnrra'  Retrre^icr.  'volume  1  Usrr  5  .MiJwuu/  CSM  UM  33^-5‘J.  Nnvernber  16,  19^1'.  and  V'r/ur’rr 
:,  Apr,U7,  IWji. 
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JOPES  relies  on  WIN  and  ALTODIN  for  data  communications.  A  dedicated 
packet-swilchmg  data  communications  subnetwork  mterconnects  WIN  sites.  It 
includes  a  store-and-forward  interface  message  processor  (IMP)  and  medium- 
and  wide-band  communication  circuits.  Tlie  JOS  Interface  Processor  (JDSIP) 
mteracts  with  WIN  ti  route  and  manage  database  updates  to  appropriate  JPEC 
sites.  Other  WIN  software  utilities  suppc>rt  tenr.u'.al-to-computer,  computcr-to- 
computer,  and  terminal-to-termmal  communications  as  shown  in  Figure  A. 4. 
Capabilities  include  TELNET,  File  Transfer  System  (FTS),  and  Teleconferencing 
(TLCE). 

Tlirough  the  use  of  JOPES  TLCFs,  JPEC  planners  can  share  electronic  mail 
messages  within  specified  groups.  TLCFs  are  usually  arranged  as  soon  as  crisis 
action  is  initiated.  Each  Tl.CF  mav  be  focused  on  a  particular  area  of 
mobilization,  deployment,  employment,  or  sustainment.  Each  has  its  access 
limited  to  a  specific  list  of  authorized  u.sers,  and  each  resides  at  a  W'WMCCS  site 
and  is  controlled  by  the  functional  database  manager  (FDPM)  at  that  site.  A 
ITCF  IS  limited  to  a  certain  amount  of  disk  space.  When  more  space  is  needed,  a 


SOURCE:  Joint  Operation  Planning  and  Execution  System  (JOPES)  Genera!  Reterence — 
Volume  1.  User's  Manual.  CSM  UM  339-90  t'Revise^i).  r-'ov.  16,  1990,  Joint  Data  Systpms 
Support  Du-'-’iiot:  v,/vniii'iu»iiv,<iiiu(u 


Figure  A. 4 — Availability  of  WIN  to  the  JPtC 


84 


new  teleconference  is  set  up  with  tlie  same  name  but  a  new  volume  number. 
Teleconferencing  was  used  extensively  during  ODS,  often  to  alert  others  that 
changes  had  been  made  to  the  deplovanent  databases. 

Security.  JOPES  meets  the  TOP  SECRET  security  requirements  for  VVVVMCCS. 
The  application  software  programs  are  unclassified,  and  users  may  classify  the 
data  up  to  TOP  SECRET,  and  unless  authorities  have  downgraded  the  data,  must 
handle  display  screens  and  computer  printouts  as  TOP  SECRET.  Users  executing 
JOPES  must  have  permission  to  access  JDS  and  have  separate  permissions  to 
different  application  catalogs. 

■Access  control  to  OPL.ANs  is  undergoing  change  as  JOPES  evolves.  Currently 
when  planning  begins,  the  responsible  CINC  will  notify  the  U'STICANSCO.VI 
functional  database  manager  as  to  the  list  of  JOPES, 'WWTvlCCS  sites  tliat  will 
share  the  plan  information  if  tliere  is  to  be  limited  distribution  of  the  plan.  With 
nomial  distribution,  the  USTIUANSCOM  FDBM  distributes  the  OPLAN 
throughout  the  network;  witli  limited  distribution,  the  plan  is  distributed  only  to 
the  ClXC's  list  of  sites.  Closely  held  or  local  (nondistnbuted)  plans  limit  the 
plans  to  the  ongmatmg  site  with  no  backup  site.  Limited-access  plans  may  also 
restrict  access  to  specific  users  and  terminals  at  specific  sites.  Use  of  terminal  ID 
restrictions  will  prevent  users  from  access  via  TELNET.  The  CJNC  may  also 
specify  a  backup  site  in  case  the  originating  site  suffers  a  failure;  if  not,  the 
default  backup  site  is  USTRANSCOM.  When  ODS  began,  the  plan  was  closely 
held  at  USCEXTCOM  and  not  shared  with  other  sites.  This  caused  some 
problem  when  the  USCENTCOM  site  had  a  failure  and  there  w-as  no  backup  site. 

The  FDBM  at  each  JOPES/ WWMCCS  site  is  responsible  for  OPL.AN  access  at 
that  site,  and  he  controls  mdividual  user  access  to  the  networked  database  and  its 
related  applications  at  tfiat  site.  This  includes  users  accessing  the  site  remotely 
from  termmals  or  w'orkstations.  At  the  current  time,  the  FDBM  has  no  control 
over  u.sers  with  proper  access  and  permissions  at  other  sites  changing  the 
plannmg  data  his  site  has  respon.sibilitv  for. 

As  a  further  restriction,  data  stored  in  the  networked  database  are  divided  into 
two  subsets — one  that  pertains  to  J5CP  OPL/XNS  and  one  that  pertains  to 
exercises  or  system  traming.  .All  user  access  and  permiss  ms  are  mamtained  for 
each  subset  of  t.he  database  and  a  user  mav  access  onl\  one  of  these  database 
subsets  during  a  given  session. 

JOPES  had  no  audit  trail  of  data  transactions  except  for  the  database 
r.,.'.nagcment  system  (DBMS)  transaction  log  until  Version  .3,  when  the  capabilits 
to  generate  a  report  of  databa.se  updates  was  installed. 


System  Performance.  JOPES  is  designed  to  provide  precise,  timeh'  information 
to  the  JPEC.  Deployment  data  precision  depends  on  the  level  of  detail  required. 
For  example,  COA  development  needs  less  mformation  detail  than  execution 
planning  because  of  uncertainties  in  specifying  the  current  situation  and  time 
limitations.  During  COA  dex’elopment,  these  constraints  mav  preclude 
development  of  detailed  force  lists  with  exact  strengths  and  tonnages  for  each 
option.  In  execution  planning,  where  a  specific  option  has  been  selected,  more- 
precise  data  are  required  to  better  manage  actual  deployment.  For  TCC 
schedulmg,  unit  movement  weights  are  specified  to  the  nearest  tent.h  of  a  ‘■hurt 
ton  or  to  the  nearest  measurement  ton.  TPFDD  data  sometimes  go  to  Level  6 
(e  g  ,  describing  personnel  to  the  job-code  level).  The  on-line  distributed 
database  is  not  currently  capable  of  processing  or  stonng  that  level  of  detail  and 
either  moves  it  into  the  SRF,  truncates  it  within  the  data  fields,  or  eliminates  the 
data  when  no  comparable  field  exists.  In  most  cases,  though,  the  on-line 
distributed  database  accepts  the  precision  of  the  reference  data  files  from  which  it 
draws  the  information. 


JOPES  Standard  Reference  Files 

JOPES  uses  the  standard  reference  files  described  above  under  JOPS  AIS: 
APORTS,  ASSETS,  CHSTR,  PORTS,  TUCHA,  TUDET,  LFF,  CEF,  TPFDD,  SRF, 
GEOFILE,  and  SORTs. 

It  also  uses  the  UAVMCCS  standard  reference  file,  NMCS  .■\utomatic  Control 
Executive  and  .AUTODL  .  (N.ACE/ AUTODlM)  files,  to  create  temporarx'  files  of 
incommg  and  outgomg  .^UTODIN-transmitted  messages.  The  Automated 
Scheduling  Message  (.ASM)  subsystem  uses  the  temporary  files  to  transmit  .ASMs 
to  ALTODIN. 

Service  and  Transportation  Command  Data  Interfaces.  JOPES  has  interfaces  to 
a  number  of  JPEC  AISs. 

Army  systems: 


DEMSTAT:  the  Deployment,  Employment,  and  Mobilization  Status  System 
provides  movement  data  of  existing  .Army  units  via  an  interface  processor  to 
JOPES  and  downloads  JOPES  data  for  review  by  .Army  components. 

COMP.A5S:  the  Computerized  Moxement  Plannmg  and  Status  System 
contains  summarized  unit  detail  data  and  provides  the  necessary  data  to 
determine  movement  requirements  for  FORSCOM  units. 
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Otiicrs: 

FLOGEN;  the  Flow  Generator  System  is  used  by  to  schedule  aircraft 
against  movement  requirements.  FLOGEN  summarizes  air  mo\  einent 
requirements  into  aircraft  loads  by  deployment  time  fr  ames,  POEs,  and 
PODs. 

COMPES:  the  Contingency  Operation/Mobility  Planning  and  Execution 
System  is  used  bv  the  Air  Force  to  standardize  and  automate  procedures  to 
select,  deploy,  and  monitor  contingency  forces  Tins  interface  is  designed  to 
source  Air  Force  OPLAN  requirements  so  that  the  TCCs  can  schedule  actual 
unit  movements. 

NCCS:  the  Navy  Command  and  Control  System  contains  command  and 
control  mformation  used  to  manipulate  Navy  data  for  OPL.ANs. 

MAll^:  tl'.e  Militar)-  Airlitt  Integrated  Reportmg  System  is  used  by  AMC  to 
monitor  aircraft  arrivals  and  departures. 

MAPS  11:  Mobility,  Analysis,  and  Plamiing  System  Version  11  is  used  by  the 
MTMC  to  schedule  CONUS  movement  requirements. 

SEASTR-AT:  Sealift  Strategic  Planning  System  is  used  by  MSC  to  schedule 
sealift  movement  requirements. 

Subsystems.  JOPES  cons:  ts  of  28  subsystems  and/or  subfiles.  Eight  of  those  are 
former  jOPS  subsystems:  FRG,  FMS.  NTG,  MRG,  LCE,  TFE,  CESPG,  and  MPM. 
Six  of  these  are  JDS  interfaces  to  AMC,  NfTMC,  Navy,  Air  Force,  Army,  and 
MSC.  The  rest  are  former  JDS  subsystems  and/or  JOPES  developed  subsystems. 


JDS  Subsystems 

Plan  Information  Subsystem/subfile  provides  the  capability  to  establish  and 
rnaintam  OPL.AN  identification,  description,  and  movement  information. 
.Additional  features  include  capabilities  to  display  status  of  OPL.AN  loads  and 
Transportation  Component  Command  (TCC)  earner  scheduling  activity. 

Requirements  Subs\  stem /subfile  provides  the  capability  to  create,  modify,  and 
delete  force  and  non-unit  records  in  the  JDS  database.  Several  displays  and 
reports  assist  m  analyzing  and  edituig  data.  Applications  allow  for  changing 
deployment  dates  automatically  and  convertmg  the  JDS  database  mto  a  JOPS 
TPFDD  format.  This  subsystem  provides  the  capability  to  merge  requirements 
from  different  sources  into  a  target  OPLA.N  and  to  rename  requirements  for  an 


OFLAN.  A  subsystem  function  can  be  used  to  create  a  partial  I'r  complete  JOF5 
TFFDD  tape  cir  disk  file  from  the  JOFES  database  with  limiting  options  a\  ailabie. 
Creation  of  a  JOFS  TPFDD  file  allows  use  of  JOFS  proceciures  to  update  the 
database.  .Also,  oUit'i  JOFS  modules  can  be  used  to  analw.e  transportatiiin 
feasibilitv  c'r  generate  resupplv  medical  support,  personnel  replacements,  or 
civil  cnginecrmg  support  requirements. 

Units  Informatics  Subsystem/subfile  performs  selected  retrieval  and  update 
functions  on  units  identified  to  fill  OFLAN  force  requirements.  It  provides  the 
capabilitv  to  rewiew  and  analvze  selected  SORTS  data,  unit  tasking,  and 
deployment  status.  (This  subfile  contains  26  of  the  approximateh'  1 26  SOR  TS 
data  element  characteristics  that  describe  a  emit.) 

Force  Module  Subsystem,'  subfile  provides  the  capability  to  rapicfly  build  and 
modify  requirements  in  support  of  COA  or  OFLAN  development  during  crisis 
situations.  The  user  can  update  or  delete  force  mc^dules;  build  or  delete 
OFLANs;  di.splay  title,  description  and  requirements  data,  and  print  reports 

Scheduling  and  Movement  Subsystem  allows  the  user  to  review,  update. 
Schedule,  and  manifest  TCC  carrier  and  organic  movement  information  both 
before  and  'during  deployment.  It  provides  the  capabilits’  to  rec  iew  and  anab.  ze 
an  extensive  variety  of  scheduling  and  movement  data  such  as  scheduled  and 
actual  deparhires  and  arrivals  of  TCC  and  organic  carriers.  Tlie  user  can  modify 
TCC  carrier  movement  manifest  data  to  fully  utilize  transportation  assets,  update 
the  manifest  subfile  as  movements  occur,  update  the  subfile  with  actual 
departure  and  arrival  time  for  TCC  carriers,  and  update  the  subfile  with  actual 
departure  and  arrival  limes  for  organic  carrier  movements. 

Records  are  entered  into  this  subfile  whenever  a  carrier  schedule  is  built.  The 
manifest  data  are  first  entered  as  planned  allocation  of  requirement  agauist 
carrier  schedule,  indicating  the  planned  ULN  to  be  loaded  on  the  carrier  but  with 
zero  passengers  and  cargo.  In  the  ideal  situation,  tlie  amount  of  passengers  and 
cargo  could  be  input  from  the  requirements  and  that  would  be  exactly  how  the 
manifest  would  read.  This  worked  m  exercises  but  not  in  ODS.  In  OD5,  the 
manifest  data  sometimes  differed  from  the  planned  alJiKation  and  tlie  planned 
allocation  was  ox  erwntten  to  show  the  actual  ULN  and  the  amoiuit  of 
passengers  and  cargo  loaded.  The  actual  manifest  data  was  entered  b\’  AMC  as 
ULNs  were  loaded  onto  aircraft. 

Retrieval  Subsystem  allows  review  of  data  from  one  or  more  subsystems  through 
on-line  display,  printed  report,  or  graphic  output.  It  prox  ides  a  single  point  of 
entry  to  all  standard  reports  and  displays. 


Iiiturmation  Resource  Manager  Siilisvstein  allows  JDS  niatia>;ers  to  perloroi  local 
database  niaiiapenient  tunctions  inckidinp  mauapini;  user  IDs,  nianapiiip,  tile 
space  for  OPl.ANs,  loading  OPLAN  TPFDDs,  etc. 

Automated  Scheduling  Message  Subs\  stein  subtile  produces  .AU  K'DIN- 
formatted  messages  from  jOPLS  data  to  provide  nun  ement  schedules  and 
summaries  'o  deplovmg  units,  command  lieadquarters,  and  port  managers 

JDS,-' AMC  Interface  Subsvstem  permits  a  direct  hnk  between  JDS  aiui  the  AMC 
Flow  Generator  (FLCKJFN)  unique  database.  Fins  allows  .AMC  systi'ni'-  to 
receue  air  moc  ement  requirements  needing  AMC  transportation  and  JDS  to 
receive  schedules  for  AMC  air  carriers. 

JDS,  NFFMC  Interface  Subsvstem  permits  a  direct  link  between  JLtS  aiui  the 
MTMC  Mobilitv  Anals  SIS  and  Planning  S\  stem,  X’ersion  11  (Maps  11)  Two 
functions  are  provided — modification  of  the  MTMC  mo\  ement  tabk-  and 
building  M  PMC  carrier  schedules  and  manitests. 

JDS  .'Monitors  Subr.vstem  provides  the  capabilits  to  monitor  the  JDS  L'pdate 
Processor,  JDS  Interface  Processor,  kx'al  and  network  tiansactum  acti\  ity,  and  the 
local/ network  status.  Tliis  subsystem  is  used  to  monitor  overall  network 
porfonnance  by  monitoring  the  last  origin  sequence  numbei  generated  lyv  or 
received  from  each  site  in  the  jOPES  network. 

JDS  ./Navy  Interface  Subsystem  permits  a  direct  link  between  JDS  and  the  Navy 
Command  and  Control  System  (NCCS)  unique  database. 

JDS/ Air  Force  Interface  Subsystem  permits  a  direct  link  between  JDS  and  the 
Contmgency  Operation/Mobility  Planning  and  Execution  System  (COMPES) 
unique  database.  This  sources  Air  Fi  ce  requirements  in  OPL/'JM  so  TCCs  can 
schedule  actual  unit  movements. 

JDS  Transaction  Editor  Subsvstem  provides  the  capability  to  edit  and  enter 
scheduling  and  requirement  transactions  residing  in  a  user  file. 

JDS/MSC  Interface  Subsvstem  permits  a  direct  link  between  JDS  and  the  MSC 
Sealift  Strategic  Planning  System  (SEASTRAT)  unique  database  to  prox  ide  data 
for  MSC  transportation  scheduling. 

JDS/  Army  Interface  Subsvstem  allows  direct  linkage  between  the  FORSCOM 
DEMSTA  r  and  the  COMPASS,  and  JOPES  UMD  subfile  and  TPFDD  Functions 
allow  the  user  to  rccox  er  UMD  data  from  tape  and  update  JDS  OPL.AN  data  with 
UMD  data  from  FORSCOM,  and  to  identify  erroneous  and/or  incomplete  data 
before  entering  it  into  the  update  process. 


Ro  loro  IK  I’  I'lli’s  allow  tho  umm  to  •-lan  tlu’  Roloronti'  fikw  Data  Hoadi’i,  tin’ 

1  rt  RP,  SORTS,  now  AIXUTIS,  Cl  IS  I  K  l  l'CllA  IVin:  1 ,  Cl  Ol  1  Ll„  LI  1 , 
OL\\rOKTS,  SDF,  lu  w  rORlS,  oto. 

Joint  OporatioiT'  Graphic  S\  stL'm  (jtXiiS)  i>  a  pii'tot\  pi’  ^raphic.s  --v  sti-in  that 
so.|''ports  lT’LAN'  ■  1 IT  PL)  data  praplw  aiivi  ilisplavs  I'li  j;r,i]’hic>-cap.ibU' 
torininaP. 

Non-  ‘andard  Cargo  Sahtile  contains  non-standard  cargo  data  about  units 
tailored  to  difter  troin  the  TT’CI  1 A  t\  pc  unit  characioristics  data  (e  g  ,  detailed 
cargo  intonnatuMi  it'r  a  unit  contigured  to  deplo\  without  its  jungle  cargo  will  he 
found  in  this  subfile  lather  than  Lite  I  L'CHA). 

Pint  Mo\  eiiient  Data  (L'MD'  subtile  contains  infi,'rmatK’n  li'r  Atin\  units 
pro\  ided  b\  1  OKSCC>M  ana  indexed  bv  LTC.  It  is  the  "real  '  cargo  detail  data 
that  has  be  a  \  alidated  and  input  by  FORSCOM  through  its  COMPASS  interlace 
tvi  jOPES.  It  describes  cargo  details  (e  g.,  tvpe,  ci'unt,  and  weight  of  v  eiuclesl. 

jOPS  Subsystems.  In  this  section  wi-  describe  thi-  1C>PF.S  capabilities  to  use  these 
subsN'stents  w  ith  JDS  subsystems,  subliles  where  appri>priate 

FK<',:  tile  force  requiri'ments  gt  nerator  (no  ji  >S  capatniitv  ,1. 

FMS;  the  force  module  sub,s\  stcm  (no  JDS  capability) 

MKG;  the  movement  requirements  generator  provides  the  following  |L^ 
capabilities — it  generates  nonuiait-related  records  from  a  JDSOPLAN,  and  it 
generates  nonunit-mci'-oment  requirenrents  in  the  on-liiie  JDS  OPLAN  bv 
using  the  JDS  "add"  transaction. 

LCE:  the  logistics  capability  estimator  provides  the  following  JDS 
capabilities — it  creates  JDS  transactions  which  mav  be  used  to  "  add"  non- 
unit  records  to  a  specified  on-line  Jl')S  Ol’L.AN,  and  it  creates  the  Force 
Record  Extract  File  (FREF)  from  i  JE)S  OPLAN. 

TFFi.  the  transportation  feasibility  estimator  allows  the  selection  e'f  a  llXs 
CtPL.AN  input  Ui  generate  TFE  movement  reijuireinents 

CESPG;  the  civil  engineering  support  plan  generati>r  (no  JDS  capabilits ) 

MPM:  the  medical  ['■Finning  me'ifule  [iri's  ides  the  capabilitc  t'  create  JDS 
transactions  which  may  be  used  to  "aefeP"  minunit  records  tei  a  specitieef  on- 
Ime  JDS  OPLAN 


NI’C:  tlu  'rn-iinit  pi'rsonnol  j;i'ner.itor  priu  ides  tlu'  i  .ip.ibilits’  to  t  roati-  JltS 
traii.'iK'tions  u  Inch  may  be  ii.sod  to  '  add  ’  noMunit  records  to  a  spa  iliod  on¬ 
line  JDS  OPLAN. 

Capabilities.  JOFLS  pro\  ides  eapabilitie.s  tiv 

•  Huild,  nu)intd;n,  and  manage  exitreise  and  leal-veorld  deplo'  ment  plans  and 
databases  siniultaneouslv. 

•  Create  an  Ol’LAN  troin  TTFDD/SRF  tonnal  'r  fri'in  Force  Modules. 

•  Ci.'n\  ert  an  on-line  OFL-oN  inti>  Fl’FDC,-  SKI-  format 

•  Add,  change,  or  delete  deployment  inlormatior.  using  ein  line  computer 
terminals  and  automated  svstems  mterlaces 

•  Schedule  and  monitor  deployments 

•  ru'c  ide  on-lme  access  to  deployment  information  usmg  DoD  standaid 
reterence  files,  e  g.,  TL'CHA,  TUDET.  SORTS. 

•  Display  depkn  iiiont  intomiation  on  computer  terimnal  or  produce  report , 
trom  a  computer  printer. 

•  Alert  units  and  installations  of  scheduled  cieployments  automaticalK  be 
ss'stem  generated  AUTODIN  message. 

•  Monitor  the  ongoing  datat'ase  system  performance  and  workioad  at  an\’ 
location  throughout  the  network. 

•  Integrate  Force  Module  capabilities  fully. 

•  l’ro\  ide  a  close-hold  environment  in  which  to  develop  OPLAN’s. 

System  Functions.  JOl'ES  provides  the  following  system  functions: 

•  Fstablish  and  maintain  a  deplocmient  database  expressuag  the  sujiported 
commander  s  requirements,  allowing  tbeJl’EC  to  coordinate  and  celine  these 
requirements  prior  to  scheduling.  Tlu*  depluv  rnent  database  consists  of 
OFLA-Ns,  CO.As,  or  OPORDs  containing  the  status,  concept,  scope,  and 
detailed  time-phased  movement  requiri'menls  tor  forces  and  sustainment. 

•  Coordinate  depluvment  schedules  with  TCCs  riii:.  includes  iliw  eloping 
detailed  deplovment  schedules,  identityiag  transjHirtatii'n  and  deln  cry 
shortfalls,  and  nranifestmg  scheduled  carriers 

•  Monitor  deploc  nu’nts.  This  inckules  general  AIS  support  tuiictions 
associated  with  svsteni  use  and  performance,  such  as  providing  access 
control  to  deployment  movement  requirements. 


Model  gloss  sustainment  requirements  (nonunit-related  supply  and 
personnel,  and  medical  planning). 

Assess  gross  transportation  feasibility  of  a  TPFDD/SRF  or  OPLAN. 
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B.  Army  Planning  Support  Systems 


III  its  deliberate  planning  and  crisis-action  planning  acth  ities,  and  during 
deployment  and  employment  of  its  forces,  the  Army  follows  joint  planning 
procedures.  It  maintains  a  number  of  Sen'ice-unique  systems,  however,  to  assist 
it  m  planning  and  execurion.  This  appendix  briefly  describes  those  systems. 

The  Army  Mobilization  and  Operation  Planning  System  (AMOP5)  establishes 
Department  of  the  Army  guidance  for  mobilization  and  deployment.  The  Forces 
Comrriand  Mobilization  and  Deployment  Planning  System  (FORMDEP5) 
establishes  the  Forces  Command  (FORSCOM)  mobilization  and  deployment 
policy. 

FORSCOM  IS  the  organization  with  pnmary  responsibility  for  (1)  mamtaining 
standard  movement  data  to  support  planning  for  mobilization  and  deployment, 
and  (2)  interfacing  the  Army  components  with  the  JPEC  through  JOPES.  In 
crisis-action  planning,  FORSCOM's  tasks  in. dude:  participation  in  Army  combat 
unit  sourcing;  responsibility  in  coordination  v  ith  Army  component  commanders 
for  CS  and  CSS  sourcing;  parlicipadon  in  time-phasing  and  transportation 
planning;  responsibility  for  validation  of  Army  planning  requirements; 
responsibility  for  assigning  CAPSTONE’  alignments  derived  from  OPLAN 
TPFDDs;  and  responsibility  for  developing  time-phasing  of  reserve  units  into 
mobilization  stations  to  meet  departure  dates  from  those  stations. 

Figure  D.l  shows  the  Army  planning  system  interfaces  to  JOPES  (and  each  other) 
at  the  VNAVMCCS  FORSCOM  site  at  Fort  McPherson.  The  next  section  briefly 
desenbes  the  Army  systems,  databases,  and  reference  files  shown  m  the  figure, 
followed  by  a  discussion  of  how  they  w'ork  together  and  future  plans.  The  last 
section  discusses  Aimy  WIS  (AWIS). 


DEMSTAT 

The  Deployment,  Employment,  and  Mobilization  Status  System  is  the 
management  system  set  up  and  maintained  by  FORSCOM  specifically  ti)  provide 
CONL'S-based  Army  installations  with  simplified  and  common  access  to 
mformation  in  a  number  of  joint  and  .Army-specific  planning  systems  JOPES, 


’CAf'STONK  IS  the  Army  program  that  ali^as  units,  regardless  of  component,  into  a  wartime 
curninaiid  .structure 


93 


%A**0t390  e  t-Of-OJ 


CONUS 

installations  Fort  McPherson 


Other 

commands 


Figure  B.l— FORSCOM  WWMCCS  Site  Showing  Army  AIS  Interfaces  to  jOPES 


MSre,  SORTS,  and  CO.''  IPASS.  It  does  this  by  providing  a  common  interface  to 
Its  OMNI  database,  allov.'ing  the  installations  to  retrieve/ read  preformatted  data 
reports  but  not  permitting  th^m  to  directly  change  the  OMNI  database. 

For  example,  if  a  user  reviewed  OMNI  SORTS  data  and  noticed  an  error  in  his 
unit's  report,  he  would  make  the  correction  in  his  next  report  to  SORTS.  The 
new  SORTS  data  would  then  (with  a  time  lag)  appear  in  the  OMNI  database  for 
further  review  by  the  unit.  Similarly,  a  user  noticmg  an  error  in  the  JOPES  time- 
phased  plan  for  his  unit  would  notify  FORSCt.  M  and  enter  a  linc-by-linc 
correction  into  DEMSTAT.  FORSCOM  would  -.heck  with  the  proper  authority  as 
to  correction  of  the  error  and,  with  approval,  forward  the  unit-prepared 
transaction  to  JOPES  (but  OMNI  would  not  show  the  update  until  it  was  later 
made  from  the  JOPES  database). 

Tlic  DEMSd  AT  interface  thus  accomplishes  several  functions:  (1)  it  provides 
users  at  re  ote  mstallations  with  the  ability  to  review  larger  amounts  of  JOPES 
data  than  their  w'orkstations  can  support;  (2)  it  protects  JOPES  from  users 


inadvertently  changing  data  that  should  be  protected  by  the  JOPES  software  but 
is  not;  and  (3)  it  allows  FORSCOM  to  fulfill  its  data  review  and  validation  role.  A 
disadvantage  is  that  OMNI  data  may  be  out-of-date  since  OMNI  is  updated  onlv 
twice  a  dav. 

COMPASS 

Tlie  Computerized  Movement  Planning  and  Status  System  is  a  FOI^COM- 
unique  system  designed  to  support  unit  movement  planning  and  requirements 
for  active-component  and  reserve-component  units  COMPASS  provides  the 
equipment  (cargo)  profile  of  deploying  units  for  JOPES 

COMPASS'S  mam  function  is  to  collect,  mamtain,  and  pass  on  unit  movement 
data  (UMD).  The  COMP.ASS  master  file  includes  five  basic  UMD  tvpes: 

•  TUCHA:  notional  TOE  data. 

•  I’EKL:  reflect '  equipment  and  accompanying  supplies  to  be  shipped  from 
CO.NUS  to  a  propositioned  equipment  set  overseas. 

•  POM:  reflects  deployment  requirements  (planned/actual). 

•  MOB:  reflects  Home  Station  to  Mobilization  Station  Movement  requirements 
for  Reserve  Components. 

•  TAILORED:  UMD  for  specific  movement  scenarios  (exerceses,  NTC,  etc.). 
Four  levels  of  equipment  da  i  are  sent  by  COMPASS  to  JOPES.  These  are: 

•  Level  1,  Aggregated:  total  number  of  passengers  and  tons  of  cargo. 

•  Level  2,  Summary:  number  of  passengers,  tonnages  differentiated  as  bulk, 
oversized,  outsi/.ed,  and  NAT  (not  air  transportable)  cargo. 

•  Level  3,  Detail  by  category:  tonnages  and  dimensions  for  each  cargo 
category  (e  g.,  wheeled  vchitlf  s,  contameri/.ed,  etc.). 

•  Level  4,  Detail  by  type  equipment:  tonnages  and  dimensions  for  each  type  of 
i-quipment  (e.g.,  type  xx  tank,  type  xy  tank,  type  yy  5-ton  truck,  etc.).^ 

TUCHA  contains  data  about  notional  units  and  is  one  of  the  main  reference  files 
accessed  by  the  JI’EC  in  plannmg  using  type  unit  information.  Periodically  in 
peacetime,  FORSCOM  prepares  LUCl  L-\  data  from  information  supplied  bv  the 

hfl  (‘xprruTK  (■->  diir:ii^  (  If  if  i-n  k  >nsl  rail’d  I  hr  mi”.,]  fur  r  xpri  s'.inp,  i  .iry’i  >  nii’iiMirr’.  ij  i  ’ll  jii.i  ri' 
ft‘fl  III  ilifritu  .wkI  sinroy.i*- 
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Department  of  the  Army,  the  Training  and  Doctrine  Command,  and  MTK-IC  and 
sends  it  to  Headquarters  Department  of  the  Army  and  to  jOPES. 

Under  peacetime  conditions  COMPASS  is  updated  once  a  day,  but  it  could  be 
updated  two  or  three  times  a  day.  Normally,  COMPASS  sends  JOPES 
transactions  to  update  trie  Unit  Movement  Data  subfile  once  a  week,  but  during 
ODS  it  often  updated  JOPES  more  or  less  frequently  depending  on  whether 
\VWMCCS  was  overloaded  and  on  the  level  of  confidence  FORSCOM  had  in  the 
UEL  data. 

FORSCOM  prepared  updated  UMD  for  ODS.  Initially,  the  ODS  data  was  a 
combmation  of  TUCH  A  and  unit  reported  POM  or  MOB  data.  Then  a  special  file 
was  set  up  on  COMPASS  and  the  units  were  asked  to  update  their  information. 

In  many  instances,  (perhaps  40  or  50  percent  of  the  time)  units  said  that  their 
UEL  had  not  changed  and  COMPASS  retained  their  previous  planning  data.  But 
as  tlie  deployment  operation  evolved,  the  data  were  corrected  to  reflect  the  actual 
movement  requirements  reported  by  more  and  more  of  the  units. 

COMPASS  data  aLso  helps  FORSCOM  to  source  units.  When  a  new  plan  begins, 
DEMSPAT  pulls  a  copy  of  the  then-current  COMPASS,  UMD  Levcl-2  detail  into 
the  OMNI  database  so  it  will  have  the  equipment-level  data  available  to  review 
and  for  sourcing  the  TPFDD.  This  was  done  at  the  start  of  ODS. 


TC-ACCIS 

The  Transportation  Coordinators'  Automated  Command  and  Control  System  is  a 
second-generation  system  that  will  automate  the  collection  and  management  of 
UEL  information  at  the  Army  unit/Army  installation  level.  It  is  mtended  to  be  a 
decentralized  AIS  tool  available  to  Installation  Transportation  Officers  (ITOs)  at 
each  Army  installation.  TC-ACCIS  is  the  Army  system  or  a  portion  of  TC-AIMS 
(Transporta... on  Coordinator's  Automated  Information  for  Movements  System), 
an  cvolvmg  jc-  nt  system  that  will  someday  include  detailed  cargo  mformation 
and  information  on  approximately  50  deployment  and  execution  events. 

Currently,  the  Uni‘  Equipment  List  (UEL)  information  is  filled  out  manually 
(through  a  series  of  forms)  by  each  unit  and  given  to  the  unit's  Installation 
1  ransportation  Officer  where  the  data  are  entered  onto  a  9-track  tape  that  is  sent 
by  ALUOLilN  to  FORSC.'O.M  to  be  logged  by  WWMCCS  security  and  read  by 


that  in  lOPFS  itu'  i  ikMaiK  for  <i  unit  (in.  mun-  .ipi’riipri.tlelv,  kir  a  UL\)  i an  hi> 
stored  m  nni’  iil  t tins'  plates:  the  l  UC  I  I.A  relerenre  file,  tite  LMl)  siitifile,  or  the  non-standard  ta r^n 
subfile  nil*  subfile  lomains  d.ita  t.ulort'd  fr(»in  (hi*  1 1  X!  I A  ddta.  It  is  used,  fur 

uxarii[’K'.  whuit  a  unit  fus  birn  tjilurvd  to  deploy  without  its  jun^U* 
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COMPASS.  It  currently  takes  about  three  to  four  da\  s  to  move  the  data  from 
installation  to  COMPASS,  much  of  which  is  taken  up  by  transporting  the  tape, 
logging  it,  etc.  With  this  procedure,  there  is  no  database  accessible  to  tlie  unit 
until  it  gets  a  report  back  from  COMPASS  perhaps  a  month  later.  Tliat  is  the 
earliest  opportunity  they  have  to  correct  errors  in  their  L'EL.  Because  of  this  time 
lag,  during  ODS  COMPASS  was  sometimes  updated  directly  by  a  unit  faxing  or 
e-rnailmg  its  UEL  to  FORSCOM. 

The  future  use  of  TC-ACCIS  will  automate  this  collection  process.'*  Tlie 
installation  will  have  its  UEL  database  available  to  units  for  review, 
manipulation,  and  correction  before  sending  it  to  COMPASS  \  ia  DDN  or 
.AUTODIN.  TC-.ACCIS  and  COMPASS  may  support  more-detailed  equipment 
information  than  JOPE5,  and  both  support  multiple  scenarios,  i.e.,  a  unit  may 
have  many  different  .AUELs  representing  its  deployment  requirements  and 
configurations  for  different  situations. 

The  installation  TC-ACCIS  systems  can  also  convert  tbio  UEL  information  into  the 
LOGM.ARS  (Logistics  Marking  and  Reading  Symbols)  system  format  and 
generate  LOGMARS  labels  for  each  piece  of  equipment  to  be  moved.  LOGMARS 
creates,  produces,  ai'id  reads  Uie  "bar  coded"  labels  that  are  stuck  on  all  types  of 
military  items.  The  transportation-related  ones  contain  the  Transportation 
Control  Number  for  the  particular  piece  of  cargo  (this  includes  a  code  identifying 
the  owner  of  the  cargo),  a  bumper  number,  model  number,  dimensions,  w'eight 
in  pounds,  cube  in  feet,  measurement  tons,  commodity  number,  type  pack,  and 
an  item  description.  At  MTMC  request,  COMPASS  will  forw'ard  LOGMARS- 
formatted  UEL  mformation  to  MTMC  via  the  WANTdCCS  File  Transfer  System. 

TC-,ACCIS  systems  are  already  installed  at  several  Army  installations  including 
Fort  Rilev  and  USAREUR,  and  future  plans  call  for  them  to  be  mstallcd 
throughout  the  .Army. 

Other  Systems 

Two  other  svstems  listed  in  Figure  B.l  are: 

MSPS — .Mobilization  Station  Planning  System.  .A  system  designed  to  support 
mobilization  station  planning  of  both  active  and  reserve  component  units 
based  on  lOPES  information.  It  maintains  and  displays  mobilization  and 
deployment-planning  information. 

rccciil  m.iiii'  after  OlTS  wai  ovtT.  of  st-mling  Iht-  direcll'  from  1 C- AC  CIS  I’v  [ILJ.Ni 
to  I  C)R.sC!OM  rwluci'd  thf  turnaround  limp  lo  about  12  hour's 
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SORTS — Status  of  Resources  and  Training  System.  This  is  a  joint  data  system 
detailing  the  readiness  of  units.  It  is  updated  once  a  day.  FORSCOM  relies 
on  SORTS  for  basic  current  information  about  a  unit,  as  does  JOPES. 

Seveial  of  the  more  important  datafiles  are: 

UMI) — Unit  Movement  Data.  UMD  describes  unit  transportation  requirements 
(pieces-vveight-cube).  This  Ls  maintairied  by  FORSCOM  through  COMPASS 
and  in  peacetime  is  updated  weekly. 

AUEL — Automated  Unit  Equipment  List.  This  is  a  product  of  COMPASS.  It  is  a 
specialized  format  of  LTMD  designed  specifically  to  facilitate  unit 
movements.  It  is  produced  by  COMPASS  m  hardcopy  and  electronic  media. 

TUCHA — Type  Urut  Cliaracterisrics  File.  This  provides  planning  data  on 

movement  characteristics  for  unit  personnel,  equipment,  and  accompanying 
supplies  associated  with  standard  deployable  t>  pe  units  of  fixed 
composition.  These  data  are  used  in  developing  and  reviewing  unit 
movemert  requirements  in  support  of  operation  plans.  Each  record  in  the 
file  is  uniquely  idenhfied  by  a  Unit  Type  Code  (UTC). 


Army  WWMCCS  Support 

AV\TS  provides  iiiformation-processing  capabilities  for  planning  and  execution  at 
eight  Army-supported  WWMCCS  sites:  Forces  Command;  U.S.  European 
Command;  U.S.  Army  Eur'^ne;  U.S.  Southern  Command;  Military  Traffic 
Management  Command;  cj  .i.  Army,  Pacific;  Headquarters,  Department  of  the 
Army;  and  the  Army  War  College.  AWIS  provides  the  Army:  (1)  WWMCCS 
equipment;  (2)  centralized  software  development  for  all  Amiy  strategic 
command  and  control  products  as  determined  by  the  JOPES  functional  model; 
and  (3)  negotiations  and  support  for  interfaces  between  Army  strategic  C2 
systems  and  JOPES.  The  Army  WVVTvlCCS  sites  receive  Army  funding  for 
maintenance  of  their  W»VMCCS  hardware. 

WWMCCS  equipment  in  use  at  FORSCOM  includes  four  Honeywell  HSOOOs 
machines  (substantially  upgraded  from  H6000s)  running  the  operatmg  system 
GCOS-8.3.  Most  decentralized  termmal  functions  are  now  performed  by  XT- 
level  PC  "workstations,"  but  almost  all  are  being  used  simply  as  dumb  terminals. 
Applications  have  been  successfully  recompiled  from  IDS  1  to  IDS  II.  The  current 
Army  planning  systems  at  FORSCO.M,  DEMSTAT,  and  COMPASS,  and  their 
interfaces  with  JOPES,  were  developed  and  are  maintained  by  FORSCOM. 
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AWlS  development  plans  are  to  replace  DEMSTAT  and  the  parts  of  COMPASS 
that  serve  the  Army  uniquely . 

The  evolving  AV\1S  software  products  are  not  intended  to  duplicate  Joint  or 
Armv  MIS  software  funchonalitv',  but  are  designed  to  complement,  supplement, 
and  implement  JOPES  in  those  areas  where  the  modernized  JOPES  software  does 
not  meet  Army  requirements. 

The  current  AVVIS  focus  is  on  building  a  modem  relational  Data  Management 
Environment  (DME)  using  Sybase  on  the  DEC  VAX  machine.  The  DME 
relational  database  design  was  a  result  of  a  full  functional  analysis  of  the  strategic 
command  and  control  needs,  which  exandned  processes  across  organizations 
utilizing  Yourdon  and  Demarco  methods.  All  data  elements  are  defined  in 
accordance  with  data  element  standards  supported  by  the  Army  Corporate 
Database  effort.  The  new  database  will  be  an  integration  of  databases  from  many 
stovepiped  systems,  and  Sybase  tools  will  be  used  to  represent  data 
dependencies  to  ensure  data  integrity  and  validation.  In  addition,  every  piece  of 
data  will  have  a  delegated  owner  who  has  sole  authority  and  responsibility  for 
any  change.  One  difficulty'  has  been  to  w'ork  through  the  security  problem.s  in 
integrating  databases  belonging  to  systents  that  had  been  individually 
accredited, 

The  AVVIS  software  lines  are  currently  being  developed  in  an  order  of 
importance  based  on  fund  availability,  current  software  limitations,  and  the 
greatest  number  of  common  requirements  that  can  be  satisfied  by  common 
software  for  the  largest  number  of  staff  users  at  the  largest  number  of  supported 
headquarters.  The  product  line  names  currently  funded  and  under  development 
a  e  Mobilizarion,  Movement  Control  and  Readiness  Reporting  (MCRR), 

Logistics,  Personnel,  and  Unit  status. 

The  .AVVIS  PMO  goal  is  to  develop  the  DME  and  AVVIS  product  lines  while  at  the 
same  time  maintaining  required  interfaces  with  thie  various  WVVMCCS/JOPES 
versio  IS.  The  PMO  has  found  it  wise  to  plot  a  course  separate  from  JOPES 
becau  e  of  past  problems  in  evolution  of  the  joint  systems  such  as  faiiurc  to 
produce  products  as  specified  or  on  schedule.  A  recent  concern  has  to  do  with 
the  new  DISA  responsibility  for  information  standards  and  future  development 
across  the  whole  DoD.  The  AVVIS  PMO  feels  that  the  .Army  is  ahead  in 
developing  standards  and  is  concerned  that  .AVVIS  product  plans  may  be  slowed 
down  or  halted  while  awaiting  DISA  standards  and  development  decisions  and 
that  AVVIS  funding  earmarked  for  product  development  may  be  channeled  to 
DIS.A.  WTat  w'ill  liappen  is  uncertain,  but  the  AVVIS  PMO  feels  it  would  be  a 
mistake  to  halt  the  current  product  line  plans  and  implementations. 


